The Seven-Step Model - Hälsodatavägledningen

This is a translation of selected sections in the Swedish (original) version of the health data guide. For more details, please visit the Swedish website.

The Seven-Step Model provides a schematic overview of an effective workflow for a project aimed at utilizing health data.

The model primarily focuses on clarifying what needs to be done, what resources are required to accomplish it, what the users’ current situation is, what kind of information is involved, how that information may and can be handled, how a solution can be developed, and how the results can be evaluated.

1. Concept

Begin by considering the core concept—what needs to be done, and for what purpose.
[Explore the Concept in more detail.]

2. Resources

To accomplish this, what competencies, financial means, and other resources are required?
[Explore Resources in more detail.]

3. User Journey

Which target groups will experience an improved process, and in what parts of the journey?
[Explore the User Journey in more detail.]

4. Information Analysis

What kind of information needs to be managed, and how should it be handled?
[Explore Information Analysis in more detail.]

5. Legal Issues

What legal requirements apply to the handling of the information?
[Explore Legal Issues in more detail.]

6. Technical Development

How should the technology be developed to enable your solution?
[Explore Technical Development in more detail.]

7. Evaluation

How will you evaluate what has been created? Does the project need to revisit any previous step to improve the solution?
[Explore Evaluation in more detail.]

Step 1. Concept

You first need an idea of how health data could support a specific user in addressing a particular problem.

One method to work with this is described in the NABC model. NABC stands for Need, Approach, Benefit, Competition, and it is often used in innovation-support contexts.

The NABC model serves as a tool to define your idea and reflect on what truly makes it valuable to your intended users or customers. It is also an excellent tool when preparing for a presentation or a so-called pitch. The model was developed at the Stanford Research Institute (SRI).

N stands for Need, the underlying problem or demand.
A stands for Approach, the proposed solution.
B is for Benefit, referring to the value or advantage for the user or customer.
C stands for Competition, meaning competing or alternative solutions.

Need

What important need are you trying to address? For whom, specifically? Give examples of companies or individuals. Talk to these people!

How many such companies/users exist? Where are they located?

How often and when does this problem occur?
How significant is the problem for the user/customer (e.g., in terms of unwanted costs)?
What are the concrete consequences if the problem remains unsolved?

Approach

What do you believe can solve the problem? What is your solution, in broad terms?

What is unique or different about your solution?
What does it cost to develop or produce?
How will it reach the customer or user?

Benefit

What is the actual customer value?

What is the benefit for the user?
What is the benefit for the person paying, in monetary terms? Consider all types of costs—for example, if something needs to be built or reorganized, that also incurs costs.
What is the customer’s ultimate gain from this (per year, per month, or another applicable period)?

Competition

What other solutions exist for the same problem?

Search online, interview industry professionals, visit stores, etc.
Do not forget the biggest competitor: the status quo. It is often easier to continue as before than to change anything at all.

Source : NABC – a model for testing your idea, LU Innovation

Next, you need to gain a general understanding of how the relevant health data would need to be generated, collected, processed, and returned to the individual(s) requiring the support. This overview is essential before delving into the details. It facilitates dialogue with decision-makers, potential owners of the health data solution, and users—or those who can represent them.

Key Questions to Consider:

What are you trying to achieve?
Who should benefit, and how?
How should it function at a high level?
What is essential, and what would be a bonus?
What is the minimum viable product (MVP) needed to make the concept interesting and relevant for the user?
Has someone already developed something similar that you could build upon, or is there potential for collaboration with someone who shares your goals?

Example: Healthy Weight – A Fictional Project

The Individual’s Role and an Initial Minimal viable product (MVP)
An individual could, for example, have access to an application for monitoring their weight. If the weight deviates from their normal range, the individual might be notified and offered guidance on how to regain control.

The application could encourage the individual to take action and track progress. As is often the case with lifestyle changes, sustainable change requires long-term support and consistent effort.

An MVP in this scenario could be a tool that displays a weight curve and offers advice when deviations occur.

The Municipality’s MVP
A municipality might need a completely different application. It could monitor weight trends across neighbourhoods. Simultaneous measures to address the issue could be implemented, and their effects monitored directly.

One feature might be the ability to track residents’ weight trends on a population level and compare them to infrastructure developments, such as the expansion of bike lanes.

An MVP here could present weight statistics and biking infrastructure per geographic area within a municipality.

Healthcare’s MVP
In healthcare settings where weight is relevant to a patient’s case, an overview of weight history might be crucial. A simple weight curve combined with a list of advice given to the patient could serve as a practical initial MVP.

Considerations

Communication Material
It is advisable to compile your conclusions in some form of communication material. Being able to clearly explain:

what is intended to be done,
by whom,
and for whose benefit,
is extremely helpful.

Nothing starts a conversation more effectively than a clear “what’s in it for me” when reaching out to potential partners.

Project Communication Toolbox

A toolbox for project communication designed for those leading projects. Here, we offer tips and links on how to effectively communicate about your project. https://swelife.se/en/swelifes-projects/project-communication-toolbox/

Checklist: The Concept

In the project, we have:

Defined the concept
Identified the benefits and their target recipients
Sketched out an MVP (Minimum Viable Product)
Investigated existing solutions
Created simple communication materials
Identified initial champions and ambassadors

Step 2. Resources

With your communication material prepared, you are now ready to reach out and engage potential funders, partners, and key experts. This will help you secure the resources your project will require.

If there are key experts who have worked on similar topics and have deep subject knowledge, they are particularly important to approach. They may be interested in collaborating on your initiative or at least offering advice on how to shape your approach. Sometimes, they may suggest a completely different path from what you initially envisioned.

It is wise to seek out representatives of your intended target groups early in the process—those who will eventually use the solutions being developed.

Example: Healthy Weight Use Case

In our example use case of promoting healthy weight, several relevant actors can be identified. These might include:

A patient advocacy organization (such as HOBS – Health Independent of Size)
Municipalities interested in designing community initiatives to address overweight and obesity
Child healthcare nurses
Specialists in obesity management within the healthcare system

It is also beneficial to identify those working on solutions at different levels of the issue. It is often more effective to build upon existing work or form partnerships to move forward together.

Planning for funding from regional, national, or international innovation-promoting entities may also require careful timing. Many recurring calls for proposals are only announced once a year.

Checklist: Resources

In our project, we have:

Analysed the ecosystem
Mapped out potential collaborations
Coordinated with partners
Initiated early contact with experts
Drafted funding applications

Step 3. The User Journey

In the third step, you focus on the experiences of your target groups and what you can do to improve them.

One way to illustrate this is by creating what is known as a user journey. In a user journey, a user—either real or hypothetical—from one of your target groups walks through, step by step, what it is currently like to perform the task or experience the situation you aim to improve. This helps identify where improvements are needed and where things are already working well.

Key questions to consider include:

How is the process affected when certain health data are made available?
At what point in the process do they become useful?
Where are the pain points in the current process, and where does it function well?
At what point do the new data make the most significant impact in achieving your goals?

Example from the Healthy Weight Case

In our case on Healthy Weight, we have not yet developed a user journey, but the figure below shows an example from another project that aimed to map the importance of information.

User Experience Example
Studies show that first-time parents often lack guidance when their child’s weight-growth curve increases more rapidly than average. They feel the issue is not taken seriously and that the healthcare response consists only of isolated efforts. This was clearly illustrated in the user journey and inspired a function where parents could receive specific guidance when the curve reaches certain thresholds.

Conversations with the target groups in this way can help clarify possible Minimum Viable Products (MVPs) and form a basis for prioritizing future actions.

Checklist: The User Journey

In our project, we have:

Described the needs of all target groups
Identified when those needs arise within existing workflows
Determined what information is needed and where
Identified how the target groups want to receive information
Created a priority list of actions
Developed a foundation for the MVP (Minimum Viable Product)

Step 4. Information Analysis

If you’ve designed a customer journey, you’ve gained a broad understanding of your intended users’ needs and where they arise. Next, it’s time to dive deep into what information – what health data – is needed to fulfil those needs.

The goal of the information analysis is for you to gain control over exactly which information must be handled, which terminology should be used, how concepts and information sets relate to one another, what (semantic and technical) format the information needs so it can be managed in your solution, how the links between different information flows look, and more.

Here you can read about:

Bring in professionals and start “good enough”
Which information, where is it, how is it structured?
Concept analysis, modelling, and code sets are central tools
Semantic interoperability
Information-analysis checklist

Bring in professionals and start “good enough”

It is wise to involve “information professionals,” such as terminologists and informaticians, in the information-analysis work. Subject-matter experts or other specialists who understand the domain should also participate.

However, you should still familiarize yourself with the issues, at least in outline. Doing so gives you better conditions for discussing information specifications and other outputs, gives you greater control over the work, and increases your chance of finding a level that is sufficiently good. Moreover, the data owners you must engage with often lack full understanding of their own data. If you understand the issues, your chances improve of asking the right questions and obtaining the “right” data in the “right” way.

Do not cut corners, but do not get stuck

A good piece of advice is not to skimp on information analysis; give it ample time. It can be challenging if parts of the information the solution is to handle are not structured at all or come from various sources in inconsistent structures.

The temptation to shortcut this step can be great, as it may seem much faster, for example, to invent your own structure or write your own definitions of key concepts. It may indeed be faster at first, but sooner or later you will meet problems when you want to scale your solution, establish collaborations, or connect it to an existing market system.

At the same time, it is easy in this step to lapse into uncompromising demands for the optimal structure. This can make the best the enemy of the good, so the work never finishes. Aim for “good enough” from the start, while planning how you can build continuous improvements into the later development of your solution. Also remember to survey what has already been done so you do not waste effort.

Start from MVPs and the customer journey

A reasonable approach is to begin with a rough sorting of the information and develop lists and models that can be refined iteratively. It is also reasonable to reduce your solution to one or more MVPs (minimum viable products) and identify the information needs per MVP, linked to your customer journey.

Example – Healthy Weight
In our case example Healthy Weight, we initially focused on clinical meetings and individual weight-height curves. For the municipality’s MVP, we chose bike lanes.

One useful aspect of focusing on bike lanes is that we could potentially collect a decade of data retrospectively – gathering weight and height data from medical records and mapping changes in urban bike infrastructure over the same time period.

Structure as close to the source as possible

Sometimes data extracted for use are so unstructured that they are unusable without major restructuring. If the restructuring is done by you as the data user, it may benefit you and your solution, but the source remains unstructured. The next user must repeat the structuring work, and your work is in effect “undone” from the source’s perspective.

Consider therefore making the structuring available to the original data owner, who can then supply the data with “your” structure to other users. The work then benefits more people, and the chance increases that your and the data owner’s solutions can exchange information with others in future. In an ideal scenario you could even require the data owner to provide data in a certain structure, though this may demand clear incentives and ample time for the owner.

Which information, where is it, how is it structured?
The starting point for information analysis is both which information is needed and whether—and if so where—this information can be obtained (under Ecosystem you will find more about sources). Some information may also need to be newly created in your solution.

Having the information well described is essential for handling it in your solution without losing meaning. If information is to be fetched from existing sources, survey those sources and study how the information is structured and described there. Add descriptions and preferably detailed specifications if available. Look for terminology, concept descriptions (even definitions), term sets (named groups of concepts), information models, and other descriptions.

If information must be newly created, you need to find suitable standards for documentation and storage. All included concepts must be specified, both how they are stored and communicated.

Structure first—standard later

A common perception is that “if we just adopt standards, all problems are solved” or “if we use international standards, everything will work.” Unfortunately, that view is too simplistic. While it is wise to use (international) standards, you cannot start with the standard and expect it to automatically give you the right information structure. Instead, begin by defining and describing your information, and then choose which standard to apply. Different standards help with different information types and situations. Also remember that the same standard can be applied in different ways.

Others May Have Done the Work

Often others have already worked on structuring the same or similar information. Make sure to inventory what exists so you avoid duplication and so you can progress further than if you started from scratch.

Foresight

The paradigm shift to mobile devices coincides with a paradigm shift to ensuring information is created as structured as possible at the point of contact between the individual and the apps or the healthcare provider. It is a golden opportunity to make better choices of terminology systems, information structures, and support for various flows.

Conceptual analysis, modelling and code sets are central tools

Many tools are available in practical information analysis. Some of the most central are concept analysis to agree on terminology, modelling to describe information needs, and code sets for structured content. It is good to orient yourself in these tools, as this will facilitate your ongoing dialogue with the experts you should engage. If the text feels too detailed or remote right now, skip these parts and return when they become more relevant.

Concept analysis provides linguistic consensus
The purpose of concept analysis is to reach linguistic consensus—that is, to agree on what the terms used in a field stand for. Concept analysis helps you identify and describe the essential characteristics of concepts and what distinguishes them from others.

Traditionally concept analysis was mainly a tool for clarifying terms to be included in glossaries and term banks, but today the method also has a natural place in information analysis. It is especially useful to understand and discuss the difference between a term (expression, technical word) and a concept (what the expression stands for). This can be helpful when comparing sources or when sketching information content and structure for newly created information in your solution.

You can find more about concept analysis in healthcare and social care in the National Board of Health and Welfare’s guide for working with concepts and terms. The guide is aimed primarily at those involved in the Board’s terminology work, but it is also a good introduction to concept analysis in general. Broad and in-depth information on terminology work is also available from the Terminology Promotion Association.

Even seemingly simple expressions can be interpreted differently by different actors or professions.

In the medicine context, an expression like the patient’s current medications can cause communication problems between healthcare and pharmacy. In healthcare it clearly means ‘the medications the patient should currently take’, but at a pharmacy it can just as well mean ‘the medications the patient currently has valid prescriptions to collect’. In collaborations between healthcare and pharmacy it is therefore important to state what is meant; otherwise misunderstandings can occur and, at worst, the patient may misunderstand their treatment.

Models provide structure
It is not enough to know what the terms stand for and how they relate conceptually. You must also control how the information about the concepts is structured in your solution—that is, how the information fits together. If the information also moves (and changes?) as your solution processes it, you must sketch the process.

There is a plethora of model types used to describe information aspects. It is not always easy to determine which type a given model is; context is needed. Nor is there full agreement on what distinguishes each model type or which are necessary in practice. This guidance advises you to start from project needs and choose model type(s) accordingly. Some variant of the following three main model types (in addition to the concept model) is often worth considering:

Flow model. A flow model describes an event focusing on who does what and in which order. Your customer journey may be a flow model, or you can develop it into one.
Process model. A process model describes an event from the perspective of what happens when an object passes through (is refined in) various stages. The object can be a product in manufacturing, but equally a patient undergoing treatment. Often the process model is drafted first, but if you start from a customer journey, process models rather break down parts of the flow into “refinement processes.”
Information model. An information model describes how information fits together or what information needs exist. Information models can describe reality as it is, but also desired requirements for how reality should be.

As noted, you should hire professional informatics help. The above description is therefore only an overview to give you a sense of the tools an informatician or information architect may use to describe information structure.

Code sets provide content to the structure
Code sets are used to specify or sort content or values in a structured way. Among the best-known code sets in health and care is ICD-10, the International Classification of Diseases. Another important code set to know is SNOMED CT.

As far as possible, try to use existing code sets (and codes). Often only parts of larger code sets are needed, and sometimes one must create so-called subsets, specified portions. SNOMED CT has subset management built into its standard tools. Subsets can then be linked to suitable points in an information model to describe where they fit in the technical solution being built. If you need to create SNOMED CT subsets or add new codes, be sure to get help. The National Board of Health and Welfare also has a special service for questions and suggestions.

Code sets for follow-up or documentation?

There is a difference between code sets and code sets. Certain types (classifications, such as ICD-10, ICD-11, KVÅ, ICF, and ATC) are best suited for follow-up, while others (clinical terminology systems, such as SNOMED CT and NPU) work better for documentation and decision support. The reason it is useful for you as an innovator to know this is that, until now, classifications have mostly been used even for documentation. Today’s documentation systems can therefore be difficult to adapt to clinical terminology systems, which would actually increase accuracy and precision in documentation. This will likely change over time, but for now you must choose whether to use the established and proven or to drive development toward new, long-term sustainable solutions. Both have advantages and disadvantages.

Semantic Interoperability

The reason information analysis is central to digital solutions is that sharing information between systems and solutions requires semantic interoperability. Simplified, semantic interoperability means that the meaning of information created in one place can be understood by the recipient elsewhere.

For the meaning truly to be transferable, it is not always enough to use the same words or the same concept definitions. The term urinary tract infection may denote the same concept, but to transfer meaning one must clarify, for example, whether it refers to a diagnostic suspicion, a possible differential diagnosis, a prescription reason, a confirmed diagnosis in general, or specifically a secondary diagnosis in a discharge note. Circumstances, purposes, contexts, and prerequisites surrounding concepts, measured values, and structures also affect transferability and interpretation. Thus, context must be evident when receiving the term urinary tract infection for true semantic interoperability. This also shows that both concept analysis and information modelling are vital tools for describing information clearly enough for transfer.

Other Forms of Interoperability

There are other aspects that affect information transfer: primarily technical, legal, and organizational interoperability.

Technical interoperability means the information can be transferred technically without distortion. The basis is infrastructure components such as power and broadband, but focus is usually on packaging and unpacking information correctly.
Legal interoperability means the information handling is permitted—that is, supported by legislation. Something being permitted is not the same as being required. For example, healthcare providers are legally allowed to release information (even digitally) to a patient unless doing so would harm the patient, yet such transfer is not routine everywhere. In health-data discussions, absence of explicit legal requirements is sometimes misinterpreted as a prohibition. If you suspect this in any matter related to your solution, consult a lawyer. Read more under Step 5: Legal analysis.
Organizational interoperability means the organizations exchanging information share similar views on factors such as political context, workflows, and business objectives. In the simplest case it can be achieved when the actors are healthcare providers with the same orientation, goals, responsibilities, and formal or informal processes. Organizational interoperability can be important for analysing where in a process a certain information type is created or needed. If information is transferred without organizational interoperability, it may be misused, misunderstood, or unused.

[Knowledge Guide on eHealth and Interoperability]

Information Analysis Checklist

In our project, we have:

Listed the information needs by location
Clarified complex terms
Analysed and described the data structure
Identified existing data sources
Investigated existing formats
Sketched process and flow models
Started building an information model

Step 5. Legal Issues

When you now know a little more about the information you would like to handle in your solution, it is time to examine what is legally permitted to do with that information. Some things you are simply required to do for the solution to be developed and marketed. Other things are not strictly necessary, but can improve the quality of the solution. Doing a little more than the minimum can also make life easier for your future customers when they have to perform the analyses required to evaluate the solution.

In this section you can read about

What must you, the innovator, do?
Legal case description – a good way to divide the solution into steps
Health data are sensitive personal data – the GDPR sets the framework
Is the solution a medical device?
Where are data stored in your solution?
Are you using third-party programs with cookies?
Do you need a legal study?
Links to health-data regulations
Legal-analysis checklist

Our message: legal issues can indeed be complicated and time-consuming, but if you get to the bottom of them you will ultimately save both time and money.

If you do not carry out a sufficiently thorough final analysis, you risk both the personal integrity of other individuals and your own finances.

Demonstrating that you have your legal affairs in order is also a mark of quality for customers and partners.

What must you, the innovator, do?

As an innovator there are certain things you absolutely must do. Items 1–3 are governed by the General Data Protection Regulation (GDPR) and are explained in more detail under Health data are sensitive personal data – the GDPR sets the framework and Where are data stored in your solution? Items 4–5 are governed by the medical-device regulations and are discussed under Is the solution a medical device?

Draw up a record of processing activities describing how personal data are handled in the solution.
Ensure that the solution has a reasonable level of security relative to the risks, and document what you have done to mitigate those risks.
Make sure the solution does not result in personal data being transferred to a country outside the EU unless an acceptable exemption applies.
Describe the purpose of your solution and, on that basis, assess whether it is a medical device and, if so, of what class.
Apply the medical-device regulations in accordance with the assessment in item 4.

In addition, you may benefit from deeper analyses:

Legal risk analysis (compliance review) – see Do you need a legal study?
Overall information-security analysis – see Not only personal data need protection
Data-protection impact assessment (DPIA) – see It is wise to carry out a data-protection impact assessment

Hire a lawyer – but read up first!

Because law is so central to development, it is wise to bring in a lawyer early. You can start with one or two workshops to document advice and recommendations, then reconnect as needed. Later, before you begin building, you will also need help with the mandatory GDPR analyses. And of course you will need the lawyer if you decide to conduct a deeper legal investigation.

Regardless of when and how you bring in the lawyer, first work through some key legal issues yourself. This helps you ask the right questions and get maximum value without excessive cost. The lawyer will do a better job if you have clear, well-structured documentation of what you know and where you are uncertain. Start by creating a case description and formulate questions based on the problems and ambiguities you identify

Legal case description – a good way to divide the solution into steps.

But first, let us dispel two myths

Myth 1: “A universal solution would solve everything!”
All-in-one plans often look brilliant at first but frequently grind to a halt because they are legally impossible. The most important advice here: ensure the solution can be divided into small steps, each with clear legal conditions (purpose, personal-data type, legal basis, controller). Only after clarifying each step should you consider merging them.

Figure text: “The magic box” where all stakeholders can share information may sound like a simple and clever solution – but from a legal perspective, it’s impossible. The solution needs to be broken down into small steps that are described separately.

Therefore, perhaps the most important advice in this guidance is that you need to ensure the solution can be broken down into small steps, where you can clarify legal prerequisites such as purpose, type of personal data, legal basis, and data controller responsibility for each step. Be systematic and thorough in this work. Only after you’ve sorted out each step is it reasonable to consider the possibility of combining multiple steps into a more complex solution.

Figure text: A breakdown into steps with clear description of legal basis, data controller responsibility, and more is necessary if the solution is to be implemented. Note that the image is schematic and only shows a selection of the requirements and possibilities you may need to investigate further. More developed examples can be found in the text below.

Myth 2: “There is no point in trying – everything is forbidden anyway.”
Initially, the legal aspects may feel hopeless and insurmountable, especially when you see the lists of relevant laws and other regulations, or when you face pushback from experienced colleagues explaining that your brilliant solution is too comprehensive to work legally. But don’t give up! When you manage to break down and describe the steps in your solution and justify why your data needs look the way they do, you’ll realize that more than you think is actually both permitted and possible. Almost no data is completely off-limits, as long as you’re clear about what you want to do with it and can justify why. However—that said, there are things that from a healthcare and development perspective might seem desirable, but which are not legally permitted today. In these cases, only changes to the regulatory framework would enable development

Examples of questions and potential solutions

1. “Standing” Referrals and Pre-Ordered Samples Allow Patients to “Order” Their Own Sampling

Only healthcare professionals can prescribe healthcare measures. However, it is possible to create “standing” referrals directed at patients who regularly need to take certain tests. The patient can then “order” sampling when needed. In reality, the “order” means that the patient activates the timing for an already prescribed sampling. The patient does this through the 1177 Self-Sampling service.

The service can also be used more broadly for common tests like chlamydia, gonorrhoea, and COVID-19. In these cases, the sampling is seen as a “resource” that the healthcare provider has ordered from an approved laboratory and paid for. The healthcare provider has then transferred to the patient the decision of when the resource should be used, i.e., when the sample should be taken.

1177 Self-Sampling (PEP) is a service provided by Inera.

2. Structured Questionnaires Enable Information Collection from Patients

Today, it is not legally possible for individuals to document information directly into their own medical record. However, it is entirely possible for healthcare providers to collect information from a patient using structured questionnaires with precisely formulated questions. The questionnaire then becomes an incoming document for the healthcare provider where the patient is treated, and the information can be stored in the patient’s record. In the PER service (PER = Patient’s Own Registration), the questionnaire can be posted as a continuously available question from the healthcare provider, which the patient answers as needed.

An example of using PER is the possibility for patients with RA (rheumatoid arthritis, i.e., inflammatory joint disease) to report their own values for a medical evaluation by a doctor.

Link to 1177 for Region Uppsala.

A more general example of PER use comes from Region Jönköping County, where the service is called Self-Registration via the Internet and is used for patients to submit information during investigation or treatment.

Self-Registration via the Internet in Jönköping County.

Challenge and Possible Development?

In the current solution for PER, no information remains with the individual; the completed questionnaire exists only within the healthcare system. This means that the individual cannot track their own values over time unless the healthcare provider chooses to share them through solutions like Inera’s Journalen.

One way to ensure that the individual retains access to their own data from the beginning could be to create a foundation as the data controller for the individual’s information. This foundation would then be responsible for developing the app and storing the values in it. Such a solution has been legally investigated but, as far as is known, has not yet been tested in practice.

In the report “Data in Your Own Hands” – an ESO Report on Personal Health Accounts, it is described how individuals could retain and store their own data in a personal health account. Among other things, the report proposes that a foundation could be responsible for such a storage service.

Data in Your Own Hands.

In “Responsibility Relationships in Digital Services, With or Without a Health Account”, it is described how the data flow between healthcare providers, medical technology developers, and patients could be designed.

Responsibility Relationships in Digital Services.

3. Release of Medical Record Information to Patients for Use in a Digital Application

Many new ideas about using health data assume that individuals can quickly, structurally, and digitally access their own medical record information from healthcare providers, enabling the information to be used and analysed in a digital solution. This could, for instance, facilitate the care of patients with chronic diseases such as diabetes and asthma.

However, even though individuals have the right to request their information, obtaining it today is practically complicated. One reason is that there are no requirements for the information to be released in a specific format — or even digitally. Therefore, individuals may just as well receive their information as printed paper copies. Another reason is that there is often a manual check to determine whether current local guidelines allow disclosure or whether a specific harm assessment must be conducted by the responsible physician. All of this takes time.

Legally, however, there is nothing preventing a healthcare provider from establishing routines to determine that a particular type of information is not considered harmful to the individual. Thus, the information could theoretically be released quickly, structurally, and digitally, allowing the individual to use it in a digital solution.

An example of what a release routine could look like can be found in Region Stockholm’s Vårdgivarguiden.

Do you think the regulations need to change? It is possible to influence…

The examples above describe solutions that work, or could work, within the framework of current regulations. However, as we pointed out before the examples, there are situations that cannot be resolved without changes to the regulatory framework.

Changing regulations is a process that often takes several years, and the consequences of such changes need to be carefully examined. Therefore, it is important that discussions about potential changes are based on concrete examples and well-founded ideas for development. If, during the work on your solution, you identify “impossibilities” that you find unreasonable, consider whether you have the time, opportunity, and willingness to proceed and assist with such examples and ideas. If so, map out the problem and the undesirable consequences you observe today, propose a solution, and describe the benefits it would bring. Make your description as clear and detailed as possible, and especially highlight what individuals would gain from the change in terms of patient safety, quality of care, and cost-effectiveness.

You should then submit your views to the forum where the legal discussion on the subject is currently taking place. Contact a government inquiry or government committee first, if you can identify one with a relevant focus. Inquiries are tasked with communicating their issues to everyone, including the general public, and are usually grateful for concrete and detailed examples from real life.
If you cannot find an inquiry, instead contact a civil servant at the Government Offices. They are obliged to answer questions on the matter, or refer you to someone who can respond or who has the mandate to investigate the issue.

Legal case description – a good way to divide the solution into steps

A good way to break down a solution into smaller steps is to create a legal case description. Through case descriptions, you can test the application of the law in a realistic, concrete situation. In this way, you can, among other things, identify uncertainties that need deeper analysis. Note that a case description does not replace a data protection impact assessment according to GDPR, but it is a good starting point for such an assessment.

It is advisable to base your work on the customer journey and the information analysis and reflect on how and between which actors the information in the solution is intended to flow, and what each actor is expected to do with the information. Central to your description is identifying who in practice decides why and how the data is handled.

Some of the questions you need to ask yourself for each step include:

What type(s) of actor(s) are involved – healthcare providers, authorities, associations, companies, or individuals?
Which actor practically determines the purposes for which data is handled and by what methods?
What do the different actors do with the information – receive it, make decisions, perform calculations, or something else?
Should information be handled at the individual level or in aggregate form?
Should individual data be pseudonymized or anonymized?
Where will the information be stored?

Through the case description, you can identify and clarify challenges and key issues related to data protection, medical device classification, and data storage in your solution.

Health data are sensitive personal data – the GDPR sets the framework

All personally identifiable health data discussed in this context are personal data. Therefore, the GDPR, the EU’s General Data Protection Regulation, applies as the baseline. Information about an individual’s health is classified as sensitive personal data under the GDPR and thus enjoys particularly strong legal protection. The basic rule under the GDPR is that it is prohibited to process sensitive personal data, meaning that for your solution to be feasible at all, you must ensure that:

it falls under one of the GDPR’s exceptions to the general prohibition on processing personal data – or, as termed under the GDPR, on processing operations,
there is a legal basis for the processing of personal data within the solution,
the processing of personal data in the solution complies with the GDPR’s fundamental data protection principles, for example, that the processing must be fair or reasonable, and that no more personal data are used than necessary for a given purpose.

A good guide on data protection and legal bases can be found at the Swedish Authority for Privacy Protection (Integritetsskyddsmyndigheten, IMY). There, you can also read about how the Swedish laws and regulations that govern the field of data protection interrelate and which laws take precedence. IMY also provides specific guidance for innovators through its Innovation Portal.

Swedish legislation complements the GDPR

The GDPR is also supplemented by national laws, which it is advisable for you to familiarize yourself with. The general complementary law is the Act with Supplementary Provisions to the EU General Data Protection Regulation (commonly referred to as the Data Protection Act).

Within the Swedish healthcare system, the Patient Data Act and the Public Access to Information and Secrecy Act are also important complementary laws. Sometimes, discussions regarding health data may give the impression that the Patient Data Act complicates the use of data, but in fact, it fundamentally acts as an enabler. This does not mean that it permits “everything,” but thanks to the Act, healthcare providers have the right to use sensitive personal data without specific consent for the purposes of delivering care, ensuring quality in operations, and other related activities.

Since January 1, 2023, the GDPR has also been complemented by the Act on Integrated Health and Social Care Documentation, which enables the sharing of information between healthcare providers and social care providers.

Controller or processor?

Among the most important aspects of your case description is to establish which entity – a natural or legal person – determines why and how personal data can be processed in your solution. In GDPR terminology, this is referred to as being responsible for the purposes and means of personal data processing. This entity is the data controller.

If another entity processes personal data according to the data controller’s instructions without being able to influence the purposes and means themselves, this entity is considered a data processor. This could involve, for example, storing data on behalf of the data controller, as you do for your customers. In practice, it can be difficult to identify who has which responsibility, but for your discussions with legal counsel, it’s important that you are familiar with these two roles.

When you, perhaps together with legal counsel, have identified data controllers and any data processors, you need to ensure that there are data processing agreements (DPA) between the data controller and the data processors, including between you and your customers. The agreements should describe, among other things, what data is involved, the rules for handling it, and whether special measures are needed to enhance privacy protection.

The Swedish Association of Local Authorities and Regions (SKR), Inera AB, and Adda AB have jointly developed a template for data processing agreements that is widely used by regions and municipalities. If you base your agreements on this template, you can both feel confident that they meet all GDPR requirements and avoid lengthy contract discussions with customers who are regions or municipalities. The data processing agreement is also available in English and is complemented by a guidance document

SKR Group’s Data Processing Agreement with guidance

As a data processor, you also need to describe for each data controller (customer) how personal data is handled in your solution. Such a description is called a record of processing activities. The information that the record of processing activities should contain is specified in the GDPR. The Swedish Authority for Privacy Protection (IMY) also has more information about this.

IMY on records of processing activities

It is wise to carry out a data-protection impact assessment

The handling of sensitive personal data can lead to a high risk for the individuals whose data is processed. Therefore, you should also conduct a Data Protection Impact Assessment (DPIA) in accordance with the GDPR. Legally, the responsibility for conducting such an assessment lies with the data controller, meaning your future client. However, it is advisable that you also carry out a DPIA yourself. In addition to gaining valuable insights into data protection, you will have the opportunity to prevent and minimize risks even before your solution is built and starts being used.

The impact assessment must be based on a risk analysis focused on data protection. Such a risk analysis concentrates on the risks to the rights and freedoms of the individuals whose personal data are handled in the solution (the “data subjects”). The risks may be material, physical, or psychological. As part of the analysis, you should also describe the measures (compensatory mechanisms) you plan to implement to protect the handling of sensitive personal data, that is, to mitigate the risks. According to the GDPR, as a supplier (data processor), you must be able to demonstrate that — and how — the personal data processed in your solution are protected.

Our recommendation is that you seek the assistance of a lawyer when conducting a Data Protection Impact Assessment. However, bear in mind that the lawyer will assess the proposal exactly as it is formulated; at this stage, the lawyer’s task is to evaluate whether you are on the right track or not, not to suggest alternative approaches. Thus, it is your responsibility to formulate your questions as clearly and precisely as possible. The clearer and more detailed you are, the greater the chance that the lawyer can conclude that your solution is realistic and feasible in practice.

The Swedish Authority for Privacy Protection (IMY) provides further information about risk analyses and impact assessments. The Swedish Association of Local Authorities and Regions (SKR) has also published an instructive template for a Data Protection Impact Assessment specifically aimed at healthcare and social care.

Not only personal data need protection

Data protection concerns personal data and the individual’s personal privacy. However, other types of information not linked to individuals can also be worthy of protection and need to be handled securely. This could include trade secrets, research or development data, innovations, or business agreements. As an innovator, you need to ensure that such data are also protected within the operations that use your solution. Your solution may even handle sensitive information from your own organization, such as patents. In that case, this information also needs to be safeguarded.

If you decide to carry out a risk analysis, it is therefore advisable not to limit it solely to data protection but also to conduct an information security risk analysis. Part of the analysis, even for this type of risk assessment, involves describing which measures (compensatory mechanisms) you intend to implement to protect the handling of the information, that is, to mitigate the risks. In many cases, the same or similar measures are needed to protect both personal data and other valuable information.

Is the solution a medical device?

As a manufacturer of technical solutions that handle health data, you are responsible for describing the intended use of your solution and determining whether it qualifies as a medical device. As the manufacturer, you are also responsible for CE marking if it becomes necessary.

Thus, you must ask yourself whether your solution is a medical device. To be classified as a medical device, a product must have a medical purpose at the individual level – examples of medical devices include defibrillators, hearing aids, medical dressings, and pregnancy tests. Applications or software with a clear medical purpose, such as clinical decision support systems, can also be classified as medical devices.

Medical devices are regulated under the EU Medical Device Regulation (MDR), and in vitro diagnostic medical devices are regulated under the EU In Vitro Diagnostic Medical Devices Regulation (IVDR). In Sweden, the Medical Products Agency (Läkemedelsverket) is the authority responsible for regulations concerning medical devices and CE marking.

If you determine that your solution is not a medical device, there may still be related regulatory frameworks you must consider. One example is the Medical Products Agency’s regulations on national medical information systems, which apply to information systems that are not themselves medical devices but are closely related in their intended use. Another relevant framework is the Product Safety Act, which applies generally to all types of consumer goods. In the forthcoming regulation on the European Health Data Space (EHDS), there may also be more explicit rules concerning electronic health record systems and health apps.

You should also consider where you are developing your solution. The Medical Device Regulation includes a specific, simplified regulation for in-house manufacturing. In-house manufacturing means developing solutions intended solely for internal use within an organization. This can become challenging if the resulting solution proves highly successful and generally applicable, making it desirable to distribute beyond the healthcare provider, or if similar products are already available on the market. In that case, the solution must be reclassified as a medical device, requiring CE marking and compliance with all other applicable requirements. Therefore, it is advisable to systematically maintain control over the documentation and other elements necessary for CE marking, even at an early stage when CE marking may not yet be required.

Even if you conclude that CE marking is not currently applicable to your product, it is still wise to clarify and document the product’s intended purpose, use, functionality, and performance. Such a description can be valuable in many other contexts – not least during discussions with legal experts.

Here are some useful links regarding medical devices:

If you plan to market your solution outside the EU, it is important to be aware that other countries (such as the USA) have different classification systems for medical devices. Conversely, if you have launched your solution in the USA and want to expand into the EU, you must be aware that regulatory frameworks differ.

Where are data stored in your solution?

A question that has been relevant for several years is whether it is sufficiently safe to use American companies and American servers for data storage. There is no national consensus on which infrastructure is acceptable to use for healthcare and health data storage. Instead, two opposing camps have emerged.

One camp believes that it is sufficiently safe, while the other argues that the personal data of European citizens risks ending up with U.S. authorities without any external oversight. The main advocate for the latter viewpoint is the Austrian lawyer Maximilian Schrems.

Schrems argues that it violates EU law for U.S. authorities to invoke national security to gain access to personal data held by American companies concerning European citizens. He justifies this by pointing out that the individuals concerned have no opportunity for insight into the use of their personal data, nor any legal means to influence it. He has brought the matter to the Court of Justice of the European Union twice, resulting in the court invalidating agreements between the U.S. and the EU regarding the transfer of personal data.

The latest development is that the European Commission adopted a so-called adequacy decision (on 10 July 2023). This decision means that the Commission now considers the protection of individuals’ personal data to be sufficiently high. In the decision, the Commission notes that there is now a requirement for U.S. authorities that surveillance and similar actions must be proportionate relative to the intrusion on personal privacy. The Commission also highlights that there is a complaints mechanism in the U.S. available to European citizens who believe their personal data has been mishandled.

It is likely that Schrems will appeal once again, but such a process will take several years. In Sweden, the adequacy decision has received a mixed response. According to some, who previously agreed with Schrems, it is now possible to use American cloud services for storing sensitive personal data. Others still argue that it is not compatible with European law. Yet others claim that it depends on the type of personal data in question.

The main takeaway for you as an innovator is that you should be aware that there is at least a hypothetical risk that personal data could end up in the hands of U.S. authorities without your ability to influence the process. In practice, you are faced with a balanced assessment of factors such as how sensitive each type of personal data truly is, the likelihood of such a hypothetical transfer happening, the costs and effectiveness of using American technology nonetheless, and so on. The number of steps recorded by a smartwatch might not be sensitive, whereas genetic information or medical history could be highly sensitive.

Moreover, the long distance to U.S. servers and legal processes can make it harder for you to maintain control over stored personal data. It may also be wise to avoid contracts with long binding periods, or at least include exit clauses, so that you can quickly switch storage solutions if the legal situation changes dramatically following a ruling by the Court of Justice of the European Union.

In summary, you still need to make your own assessment regarding the handling of personal data in your solution. In more complex cases, it is advisable to seek support from lawyers and information security experts. At a minimum, make sure you are fully aware of what decisions you are making, why you are making them, and that you are able to explain and justify them.

[Adequacy Decision – 10 July 2023]

Are you using third-party programs with cookies?

A particular aspect of storage concerns cookies. Cookies are small text files that are stored on a computer, tablet, or mobile phone when a user visits a website. The cookies contain information about the browser, IP address, screen resolution, and activities on the website. This can include what content the user has viewed and clicked on at a given time, and which website the user visited before arriving at the current website.

Today, laws and established practices require the implementation of a so-called cookie banner—a dialog box that, upon a user’s first visit to a website, informs them about the cookies present and allows them to choose to decline all cookies except those that are strictly necessary. A cookie banner must offer at least three quick options:

A button where the user can decline all cookies except the necessary ones.
A button to accept all cookies.
A button where the user can make individual settings for each type of cookie.

If you use third-party software in your solution, you must also investigate what cookies the software uses. For example, it is ethically questionable to build a solution targeted at municipalities or regions and include cookies where the provider or a third party can direct marketing of commercial services or products to the users. It is also important to verify that the third-party software or cookies do not transfer personal data to recipients in third countries.

[Guidance on AI in healthcare – Swedish Medical Products Agency]

Do you need to conduct a legal investigation?

In some cases, there may be reasons to have a legal expert conduct a legal investigation with a different focus than the data protection impact assessment and the information security risk analysis. This may be particularly appropriate if the legislation has recently changed or is about to change, or when dealing with large and costly solutions.

The level of ambition and scope of such work can vary depending on the nature of the solution, your own legal knowledge, your financial resources, and so on. You might want to ensure that the solution stays within the framework of all applicable regulations. This is sometimes also referred to as a legal compliance review.

Depending on what you agree upon, the legal expert may limit their work to answering specific questions, or the assignment may involve broader responsibilities and more in-depth analysis. This can include detailing the case description, examining and clarifying questions about exactly who will handle which data and how, identifying potential legal issues based on the case description, proposing and describing one or more alternative solutions, and identifying the risks associated with these at various stages.

Regardless of the level of ambition, the case description(s) you have prepared form a good starting point for the legal expert. If not already included in the case description, you should also supplement it with:

A text-based description of the service, including architecture, actors, and information flows
A text-based description of the technical and organizational security measures you plan to implement to protect the handling of sensitive personal data
Illustrations that clarify (note that illustrations alone are not sufficient)
Clearly formulated questions where you need specific advice.
[Four examples of legal reviews – knowledge-management page, bottom]

Links to health-data regulations

Further relevant laws and regulations

In addition to these, it may also be beneficial for you to familiarize yourself with additional laws and regulations that directly or indirectly affect the handling of data within healthcare and social care. Please note that this guidance focuses primarily on Sweden and secondly on the EU. Other EU countries have their own complementary national legislation, different from that of Sweden, and countries outside the EU have legislation that may differ from the EU’s.

[Health and Medical Services Act (HSL)]

The Health and Medical Services Act (HSL) is the central law for healthcare in Sweden. It provides overarching goals and guidelines for operations, based on the principle that the aim of healthcare is to ensure good health and care on equal terms for the entire population.

[External link Social Services Act (SoL)]

The Social Services Act (SoL) is the central law for social services operations in Sweden.

[External link Act on the Processing of Personal Data within Social Services (SoLPuL)]

This law regulates when personal data may be processed within social services.

[External link Patient Act]

The Patient Act aims to promote the patient’s integrity, autonomy, and participation.

[External link The National Board of Health and Welfare’s regulations and general advice on record-keeping and processing of personal data in healthcare]

These regulations describe, among other things, the minimum information that must be included in a patient record and that each individualized care process must be presented clearly.

[External link The National Board of Health and Welfare’s information about regulations and general advice]

Here you can find a complete list of the agency’s current regulations.

[External link Act on Information Security for Essential and Digital Services]

This law is based on the EU’s NIS Directive. The NIS Directive aims to achieve a high common level of security in networks and information systems across the EU. The legislation applies to providers of essential services for networks and information systems.

Legal-analysis checklist

In the project we have:

created a processing-records register
clarified controller responsibility in different parts of the solution
drafted case description and questions for the lawyer
clarified any third-country transfers and their basis
described and classified any medical device
described how risks are to be mitigated

Step 6. Technical Development

The difficult part is not creating a technical solution that does what we want. The real challenge lies in achieving interoperability and ensuring that the solution integrates with existing systems and future maintenance structures.

A common mistake is postponing considerations around maintenance for too long, which can make it difficult, costly, or even impossible to find someone willing or able to take over the maintenance of the solution. A key success factor for the long-term sustainability of your solution – and therefore the viability of your work – is to find actors who see an intrinsic value in it. This will make them more interested in keeping the solution alive in the future.

If you have prepared a customer journey description, the information content, and a legal target image from the previous steps, you now have a strong foundation to design a technical solution. With this solution, you can develop your MVPs (Minimum Viable Products) to test with users from your target groups.

Reuse Previous Solutions

If there are existing solutions you can build on, this is the right time to explore concrete opportunities for collaboration with those who developed them. There may be opportunities to reuse parts of previous solutions. Consider whether it is possible to cooperate on new solutions that need to be developed and where these solutions should be placed for continued maintenance.

During the development work, requirements gathering and ongoing risk analyses usually take place. The information specification may be adjusted, and possibly also the use cases. The technical solution is described in a System Architecture Description (SAD).

Some parts of the technical solutions may need to be procured, which becomes a separate process that can take additional time. Do not forget to plan procurement activities early.

Collaboration and Maintenance

A common problem – especially when a project has been awarded “moderate” funding – is that the construction work begins without fully exploring potential collaboration partners. Partners can share costs and the effort involved in further development and maintenance. It is often only when the funding dries up that one realizes the importance of having invested time and resources early on in building strong collaborations.

Checklist: Technical Management

In the project we have:

Divided technical components per step/container
Conducted a risk analysis regarding information security
Implemented privacy-enhancing measures
Appointed responsible entities/owners
Designed quality monitoring measures
Documented the system architecture design

Step 7. Evaluation of the MVP

Now you have at least a first version, a Minimum Viable Product (MVP), of your solution. This is the appropriate point to begin the evaluation process to verify that the solution is being built correctly and to validate that the right MVP is being developed.

There are many ways to evaluate the MVPs that have been created. The crucial aspect is to constantly focus on how users perceive the benefit of the solution and their thoughts on further development. If the target groups feel that the solution is helpful, the odds of the project continuing increase dramatically.

You and the project team can now improve the MVPs and aim to scale up the solutions, integrate them with the broader ecosystem, and find models for maintenance and continued development.

Engage in Discussions with the Target Group

Include discussions with the target group as part of the evaluation, for example through focus groups. Having several people reflect and exchange thoughts often leads to better analyses.

Semi-Structured In-Depth Interviews

One powerful method for exploring important issues is through semi-structured in-depth interviews. These are interviews where you combine structure (discussion areas with a few initial questions) with a free-flowing interview that allows the conversation to evolve naturally. This method can elicit answers to questions that individuals might not feel comfortable sharing in a larger focus group setting.

To ensure a deep and meaningful discussion in the freer parts of the interview, it is important that the interviewer has good knowledge and understanding of the subject matter—what is often referred to as strong prior knowledge.

Suggestion Box

Having a suggestion box where people can submit comments during the project can not only provide material for a Frequently Asked Questions (FAQ) summary but can also reveal interesting patterns of needs and highlight issues that require special attention.

Quality Assurance

It is valuable to systematize a process for the quality assurance of the data being handled. This way, you can feed back into the continued development of the MVPs. It also contributes to the ability to start compiling various forms of statistics and describing the data for future research opportunities.

For example, health economic simulations are particularly interesting in the near term, as they can make the difference between whether a project receives continued support or not.

Share Your Results

Finally, we collectively need to become better at publishing what we accomplish in our Swedish projects. We should improve in showcasing what we do and succeed with internationally. It is also important to share experiences on how projects can be run more efficiently and deliver greater benefits to their target groups.

Checklist: Evaluation of the MVP

In the project we have:

Collected experiences from the target groups’ focus groups
Considered semi-structured in-depth interviews
Compiled a suggestion box/idea box into a FAQ
Assessed data quality through sampling and other methods
Attempted to conduct health economic simulations
Published articles in various channels