eu data act connected medical devices · medical device data access
EU Data Act: Connected Medical Devices Data Access in 2026
October 28, 2026
23 min read
A 2026 engineering guide to EU Data Act connected medical devices: scope, Articles 3 to 5, field catalogs, authorized API access, GDPR safeguards, disclosures and release evidence.
- 01The Data Act generally applied from 12 September 2025. Its design obligation applies to relevant connected products and related services placed on the market after 12 September 2026.
- 02A hospital using a device and the patient represented in its data can have different roles. Data Act access rights do not themselves supply a legal basis for disclosing another person’s personal data.
- 03Classify individual measurements, events, service interactions and analytical outputs. Raw and pre-processed data require different assessment from inferred or derived outputs, with necessary metadata accompanying accessible data.
- 04Users receive access free of charge. Direct access depends on relevance and technical feasibility, while request routes and user-directed third-party sharing need authorization, recipient and purpose controls.
- 05Link the field catalog to deployed interfaces, permissions, customer disclosures and delivery evidence. The proposed coverage calculation measures implementation completeness and does not replace legal or safety review.
Executive Summary
The EU Data Act applies to connected medical devices, and its Article 3(1) design obligation applies to connected products and their related services placed on the market after 12 September 2026. ([1]) ([2]) Its general application date was 12 September 2025, so the later design milestone should not be treated as the start of all user-access obligations. ([3]) For a manufacturer, the practical deliverable is a documented path from each relevant data field to an accessible output, associated metadata, an authorized user and an accurate pre-contract disclosure.
The scope assessment starts with the product, service and parties. A hospital owning equipment can be a user, while a patient represented in its measurements is a data subject; those roles require separate assessment. The Data Act does not itself supply a personal-data legal basis when the user is someone other than the data subject. ([4]) The Commission distinguishes accessible raw and pre-processed data from inferred or derived outputs. ([5]) Consequently, an implementation should classify measurements, operating events, service interactions and analytical outputs individually, rather than treating an entire database as either accessible or excluded.
Access by design does not mean unrestricted access. Direct access is required where relevant and technically feasible; a request route remains relevant where direct user access is unavailable. ([6]) ([7]) Users must receive access free of charge. ([8]) Privacy, identity verification, confidentiality and device safety should therefore be implemented within the access workflow. Health information remains subject to the General Data Protection Regulation (GDPR), including its special-category conditions. ([9])
This report recommends a field catalog linked to interfaces, a policy service that evaluates requester and recipient rights, proportionate verification, and evidence showing what was disclosed and delivered. OpenAPI, Fast Healthcare Interoperability Resources (FHIR) and OAuth can support these components, but they are implementation options rather than Data Act mandates. ([10]) ([11]) The proposed coverage calculation measures implementation completeness, not legal compliance. Finally, teams should track legislative change: the Council agreed a Digital Omnibus negotiating position in October 2026, while Parliament’s procedure remained at committee stage when checked for this report. Those records establish an ongoing legislative process, not completed replacement rules. ([12]) ([13])
General Data Act application date
Design obligation applies to relevant products and related services placed on the market after this date
Introduction and Background
Connected medical equipment can generate operational records alongside clinical measurements. Determining who can retrieve those records requires more precision than a statement that a device is connected. The Commission explicitly identifies medical devices within the connected-product examples covered by the Data Act, and Germany’s Bundesnetzagentur includes equipment used for monitoring and diagnostics. ([1]) ([14]) The appropriate starting point is therefore the individual product and its data flows, followed by an assessment of the applicable obligations and exceptions.
This report addresses product leaders, architects, privacy teams and regulatory counsel making release decisions for the European Union (EU). Its reference date is 28 October 2026. The key statutory distinction is between the Data Act’s general application and the later application of the design obligation to products and related services placed on the market after the specified deadline. ([2]) A product program should record the relevant placement facts rather than assume that a model name or software release date settles that question.
IntuitionLabs’ editorial perspective in this report is that an access commitment should be traceable to a working capability and its supporting evidence. The architecture below is an analytical recommendation. It does not represent a prescribed EU technical specification, and it does not replace a device-specific legal assessment.
Three kinds of material are kept distinct throughout: requirements drawn from the regulation, explanatory guidance from public authorities, and proposed engineering controls. That distinction matters because even useful official implementation guidance can be provisional. The Netherlands Authority for Consumers and Markets (ACM), for example, describes its published Data Sharing Guidelines as provisional pending further Commission guidance. ([15]) Readers should ask EU counsel to assess product scope, enterprise exceptions, personal-data permissions and proposed restrictions before relying on a particular interpretation.
Key Changes
Access becomes a design and release consideration
Article 3(1) requires product data, related-service data and necessary interpretive metadata to be accessible by default, easily, securely and free of charge, in a comprehensive, structured, commonly used and machine-readable format. Direct user access is required where relevant and technically feasible. ([16]) Ireland’s Competition and Consumer Protection Commission (CCPC) identifies a built-in interface, an application or another technical tool as possible access mechanisms. ([17])
The recommended release control is a documented access design reviewed alongside the product’s data architecture. It should state which outputs are available locally, through a service, or through an electronic request. When direct access is unavailable, record the technical reasoning, affected fields and alternative route. CCPC specifically recommends demonstrating and documenting the reasons for that decision. ([18])
A working screen alone is weak evidence of comprehensive machine-readable access. The implementation review should inspect the exported values, metadata and available history. This follows from the statutory emphasis on usable data and the request-based requirement for quality equivalent to that available to the holder. ([19])
Disclosures become part of the product specification
Article 3(2) requires information before a purchase, rental or lease contract, including data types, formats, estimated volumes, continuous or real-time generation, storage, intended retention, access mechanisms and relevant terms or quality of service. Related-service disclosures under the following paragraph add information such as collection frequency, the data holder’s identity and intended data uses. ([20]) ([21])
The engineering implication is to maintain these statements from the same controlled catalog that describes the actual outputs. A catalog change should trigger review of affected customer disclosures. ACM similarly emphasizes explaining what data are collected and how users can consult or request them. ([22]) This creates a useful acceptance test: the described retrieval method should work against the released configuration.
Sharing requires recipient and purpose controls
Article 5 gives users a route to request that readily available data and necessary metadata be supplied to a third party, without undue delay and free of charge to the user. ([23]) Traficom lists user-requested third-party sharing among data-holder obligations. ([24]) Product teams should therefore design delegated access, not assume that a personal download completes every sharing requirement.
The recipient workflow needs its own eligibility and purpose checks. Designated Digital Markets Act gatekeepers are not eligible third-party recipients under the relevant provision; recipient use is subject to agreed purposes and restrictions, including the prohibition on developing a competing connected product. ([25]) These rules should be translated into recipient registration, contractual terms and authorization policy, with legal review of the proposed use.
The commercial workflow also needs a separate branch. Free user access does not eliminate the regulation’s business-to-business compensation framework. A holder must explain the basis of compensation sufficiently for the recipient to assess it against the statutory conditions. ([26]) Recommended access records should distinguish the user’s request from any recipient agreement.
Implementation Considerations: Scope and Roles
Decide scope through product and role questions
Apply the following decision sequence to each product configuration. It is a proposed review method, not a substitute for the statutory definitions.
- Product: Determine whether the item obtains, generates or collects use or environmental data and communicates product data electronically, physically or through on-device access. ([27])
- Related service: Test whether software is functionally linked to the product, including services whose absence prevents a function or which subsequently add or adapt functions. Do not classify every application used in a hospital as a related service. ([28])
- Territory: Check EU-market placement and the relevant EU user relationship. A manufacturer’s establishment outside the EU does not by itself remove the product from scope. ([29])
- Enterprise exception: Have counsel test the qualified micro- and small-enterprise exclusion, including partner, linked-enterprise and subcontracting conditions. It is not a general exemption for every company describing itself as small. ([30])
- Temporary treatment: The exception also addresses enterprises qualified as medium-sized for less than one year, and connected products for one year after placement by a medium-sized enterprise. Assess those time limits against documented company and placement facts. ([31])
- User: Identify ownership, contractual temporary-use rights and receipt of related services. ([32])
- Data holder: Identify the entity with the relevant right or obligation to use and make data available. Do not infer that role solely from the location of a server. ([33])
Maintain separate requester, organization, product and patient identifiers. France’s Commission nationale de l’informatique et des libertés (CNIL) notes that several users can coexist for one connected product. ([34]) A fleet account should therefore be assessed against its entitlement to particular devices, time periods and records, rather than receiving access solely because it belongs to the same institution.
- A hospital owning equipment can be a user.
- Users can request that readily available data and necessary metadata be supplied to a third party, without undue delay and free of charge to the user.
- A patient represented in the equipment’s measurements is a data subject.
- Where user and data subject differ, assess a valid GDPR legal basis and additional health-data conditions.
The Data Act does not itself supply a personal-data legal basis when the user is someone other than the data subject.
“A high ratio can coexist with a missing important field or an incorrect scope decision. The proposed metric is therefore useful for finding incomplete work and showing changes over releases, while legal and safety reviews remain independent acceptance conditions.
Data Classification and the Access Catalog
Product data concern data generated through product use and designed to be retrievable. Related-service data represent digitized user actions or product-related events recorded during the service. Readily available data are the relevant data that the holder lawfully obtains or can lawfully obtain without disproportionate effort beyond a simple operation. ([35]) These categories answer different questions: origin, relationship to the service, and availability to the holder.
Do not equate “processed” with “inferred.” The Commission includes raw and pre-processed data in its scope explanation while excluding inferred or derived data and content. ([5]) The recommended classification record should describe the transformation and explain its conclusion. Necessary metadata should travel with the accessible output; catalog interoperability can be supported by the World Wide Web Consortium’s Data Catalog Vocabulary (DCAT). ([36])
Table 1 illustrates a proposed field catalog. Every example is hypothetical; formats and frequencies below are design choices, not claims about a commercial device.
| Illustrative field (Hypothetical Example) | Classification question | Proposed metadata and delivery record |
|---|---|---|
| Sensor measurement | Is it retrievable product data, and whose personal data does it reveal? | Unit, calibration context, observation time, source device, available history and access route. FHIR Observation offers an optional measurement model. ([11]) |
| Pre-processed measurement | Does the transformation prepare a reading for use, or generate a distinct inference? | Transformation description, source linkage, quality flag and classification rationale. |
| Operating event | Is it generated by product use and retrievable? | Event code, timestamp meaning, device identity, retention and export format. |
| Service interaction | Does it record a user action or event within a related service? | Actor role, affected product, event meaning, collection frequency and service access route. |
| Analytical score | Is it genuinely inferred or derived, and are its source measurements separately accessible? | Separate entries for the score and inputs, with the reason for each scope decision. |
| Patient identifier | What legal basis and special-category condition permit the proposed disclosure? | Recipient permissions, purpose and minimization controls. Health information requires particular assessment. ([9]) |
| Metadata | What does a recipient need to interpret and use each output? | Schema, units, enumerations, timestamp semantics, provenance and version. Provenance can describe producing entities and activities. ([37]) |
For every field, the proposed catalog records its source, data holder, relevant user role, classification, format, units, generation and collection frequency, available history, retention and access route. Add quality-of-service characteristics such as delivery frequency and known gaps. Distinguish sensor generation from cloud collection and export availability; a statement that a device generates continuously does not describe every later stage. Keep those descriptions aligned with the pre-contract disclosure. ([21])
The catalog should preserve distinctions that a database schema alone can obscure. A mixed record may contain accessible measurements, personal identifiers and an inferred output. The proposed approach is to classify components and assemble an authorized response, with explanations for any restriction. Metadata and endpoint descriptions should remain linked; DCAT includes descriptions of service operations and parameters. ([38])
Access Architecture: Direct Retrieval and Third-Party Transfer
Provide a usable access path
Select the simplest architecture that meets the assessed obligations and device constraints. A local export, an authenticated service or an application programming interface (API) can support different workflows. CCPC’s examples are technology-neutral, while ACM describes an easy online request route where direct access is technically unavailable. ([17]) ([7])
For request-based access, preserve the statutory conditions in the acceptance criteria: relevant readily available data and metadata, without undue delay, at the quality available to the holder, securely and free of charge to the user. Continuous real-time delivery is qualified by relevance and technical feasibility. ([19]) An implementation should record available sampling and delivery characteristics without presenting an arbitrary engineering service target as a legal deadline.
Separate extraction, policy evaluation and delivery in the proposed service. Maintain a versioned interface contract: OpenAPI describes Hypertext Transfer Protocol (HTTP) APIs, using JavaScript Object Notation (JSON) documents. ([10]) ([39])
Implement a controlled transfer sequence
Recommended transfer sequence:
- Register the requester: Bind the account to the asserted organization or individual and the relevant device entitlement. The United States National Institute of Standards and Technology’s (NIST) Internet of Things (IoT) capability catalog identifies unique logical and physical device identification as a useful security capability. ([40])
- Verify proportionately: Request the evidence needed for the access decision. The Irish Data Protection Commission advises limiting additional identification information to what is necessary and proportionate when handling data rights. ([41])
- Register the recipient: Record its identity, service and proposed purpose; assess legal eligibility before issuing access.
- Record the instruction: Capture the user’s requested fields, devices, period and recipient. Keep the instruction separate from the personal-data legal-basis assessment.
- Evaluate policy: Resolve entitlement, personal-data permissions, confidentiality conditions and any justified safety restriction before creating the response.
- Issue limited credentials: Where OAuth is chosen, follow current security guidance, including Proof Key for Code Exchange (PKCE), appropriate redirect validation and restricted token privileges. ([42])
- Deliver and terminate: Record delivery outcomes, provide the agreed stopping mechanism, and enforce expiry or withdrawal in the authorization service.
OAuth handles technical delegation; it does not establish every legal condition for health-data sharing. Bundesnetzagentur identifies the separate legal-basis question where the user and data subject differ. ([4])
For an OAuth implementation, require exact matching of preregistered redirect addresses subject to the specification’s native-application exception. Use audience restrictions and sender-constrained tokens where appropriate to the deployment. ([43]) ([44]) Scope tokens to the approved resources and operation, and make revocation testable rather than merely describing it in a contract.
Separate measurements, timestamps and records of access
Name observation, upload and export times separately. FHIR’s version-pinned Observation model includes a clinically relevant time or period. ([45])
Use a separate security event record for access activity. FHIR AuditEvent is designed for security logging and can represent the outcome of an event. ([46]) Logging should support reconstruction of the access decision without copying all disclosed clinical data into another store. Apply privacy minimization to the log itself, including the information retained and who can retrieve it. Audit design should have its own necessity and retention assessment. ([47])
Bind the account to the asserted organization or individual and the relevant device entitlement.
Request the evidence needed for the access decision. Limit additional identification information to what is necessary and proportionate.
Assess recipient identity, service, purpose and eligibility. Record the user’s requested fields, devices, period and recipient separately from the personal-data legal-basis assessment.
Resolve entitlement, personal-data permissions, confidentiality conditions and any justified safety restriction before creating the response.
Where OAuth is chosen, use PKCE, appropriate redirect validation and restricted token privileges in line with the cited security guidance.
Record delivery outcomes, provide the agreed stopping mechanism, and enforce expiry or withdrawal in the authorization service.
Privacy, Medical-Device Safety and Confidentiality Controls
Treat GDPR permissions as an independent gate
CNIL explains that GDPR prevails if the Data Act conflicts with personal-data protection. ([48]) Existing GDPR rights can also coexist with Data Act access rights. ([49])
Identify controller and processor relationships for each disclosure. Where user and data subject differ, assess a valid GDPR legal basis and additional health-data conditions. Bundesnetzagentur identifies Article 6 and, where applicable, Article 9 and ePrivacy requirements; Ireland’s regulator explains health data’s special-category status. ([50]) ([9])
Recommended privacy review questions include:
- Purpose: What precise service or activity will the recipient perform?
- Necessity: Which personal fields are needed for that purpose?
- Authority: Who can instruct the transfer, and what permissions remain independently necessary?
- Retention: How long should the recipient and the access service retain their respective records?
- Risk: Does the processing require a data protection impact assessment (DPIA)?
The European Data Protection Board (EDPB) explains that privacy by default limits processing to what is necessary for each specific purpose and that likely high-risk processing requires a DPIA. ([47]) ([51]) Spain’s Agencia Española de Protección de Datos (AEPD) separately recommends defining strict retention limits. ([52])
Integrate access changes with device risk management
Medical Device Coordination Group (MDCG) guidance links security controls affecting safety or effectiveness to the safety-risk assessment, and identifies testing as the primary means of security verification and validation. ([53]) ([53])
Assess access changes under applicable Medical Device Regulation (MDR) and In Vitro Diagnostic Medical Devices Regulation (IVDR) duties. MDCG connects software development, information security, verification and validation to these frameworks. ([53])
The recommended design separates the data-delivery workload from functions whose availability or timing is clinically important. Test authorization failures, concurrent export requests, malformed requests and interruptions against the applicable device risk analysis. NIST’s capability catalog supports protecting stored and transmitted data and restricting logical access to authorized entities. These are useful engineering references, not EU Data Act mandates. ([54]) ([55])
International manufacturers can reuse suitable evidence across programs while retaining the jurisdictional distinction. The United States Food and Drug Administration’s (FDA) cybersecurity guidance addresses design, labeling and premarket documentation; it does not establish the EU access requirement. ([56]) The UK Information Commissioner’s Office (ICO) addresses lifecycle privacy design, as comparative guidance. ([57])
Apply exceptions through a documented decision
The Data Act’s security restriction concerns legally established requirements and serious effects on people; a generic security preference does not express that statutory test. ([58])
- Personal-data permission gap: Establish the missing legal condition or limit the response to data that can lawfully be supplied. A user’s commercial entitlement does not establish a legal basis for another person’s data. ([4])
- Safety restriction: Document the applicable security requirement, the serious health, safety or security effect, the agreed restriction and any required authority notification. ([59])
- Trade-secret safeguards: Identify the protected data and proportionate confidentiality measures before determining the disclosure route. ([60])
- Exceptional refusal: Distinguish missing or ineffective safeguards from the stricter, case-specific serious-economic-damage test for refusal despite safeguards. Document reasons and required notifications. ([61])
Record affected fields, evidence, owner, reconsideration conditions and complaint route. National responsibilities can differ; Germany identifies a distinct role for its federal data-protection authority in overseeing personal-data processing. ([62])
Contract Disclosures, Testing and the Evidence Pack
Maintain a controlled relationship between the data catalog, customer-facing disclosure and deployed access capability. Traficom’s detailed guidance includes pre-sale information on generated data volume, generation characteristics, storage and retention. ([21]) Related-service information requires additional attention to collection frequency and the service relationship. ([63])
Table 2 maps selected requirements to proposed controls and evidence. The control choices are recommendations; the cited sources establish their underlying requirements or relevant technical patterns.
| Requirement or objective | Proposed control | Review evidence |
|---|---|---|
| Accessible data and metadata | Test local and service access against approved catalog entries. | Output samples, schemas and a documented direct-access decision. ([18]) |
| Comprehensible pre-contract information | Generate disclosures from approved catalog content. | Versioned customer document and comparison with released behavior. ([22]) |
| User-requested third-party sharing | Bind recipient grants to the recorded user instruction. | Recipient record, authorization decision and transfer outcome. ([24]) |
| Purpose-limited authorization | Restrict credential privileges to approved resources and operations. | Authorization configuration and negative test results. ([64]) |
| Machine-readable interface description | Maintain a versioned interface contract and schema. | OpenAPI document and operation-level security definitions. ([65]) |
| Proportionate identity checks | Define acceptable evidence according to access risk. | Verification policy and minimal decision record. ([66]) |
| Security and delivery audit | Record requester, decision, operation, time and outcome. | Protected event records with a defined retention policy. ([67]) |
The evidence should connect the customer’s experience to a specific released configuration. A contract template alone cannot show whether a requested field arrives with usable units and timing. Conversely, an export test cannot show what the buyer was told before contracting. Read the two records together.
The Commission’s model contractual terms can inform drafting, but their use is voluntary and users can amend them. ([68]) The recommended contract review should preserve the distinction between data access, personal-data permissions, recipient obligations and compensation, rather than compress them into one undifferentiated acceptance box.
A practical release evidence pack should contain:
- Scope record: Product, service, territorial and enterprise assessments with responsible owners.
- Catalog baseline: Approved field classifications, metadata and access characteristics.
- Permission record: User entitlement, recipient eligibility and personal-data assessments.
- Delivery evidence: Successful requests, denied unauthorized requests and termination behavior.
- Lifecycle record: Disclosure versions, retention decisions and review triggers.
The European Union Agency for Cybersecurity’s (ENISA) healthcare procurement guidance covers the procurement lifecycle and identifies information suppliers should provide. ([69]) ([70]) This supports organizing the pack so a hospital’s technical and privacy reviewers can find evidence without relying on a sales description. Documenting design decisions also follows AEPD’s privacy-engineering guidance. ([52])
Data Analysis and Evidence
- 2025General application12 September 2025
Assess existing access and disclosure obligations independently of the later design milestone.
- 2026Design obligation after the milestoneAfter 12 September 2026
The design obligation applies to relevant products and related services placed on the market after this date. Record placement facts in release evidence.
Use the relevant dates, without inventing a market benchmark
The quantitative core for this implementation decision is statutory timing and measured product coverage. This report does not establish a medtech-wide compliance rate, a typical API implementation cost or a sector adoption benchmark. Its coverage metric below is a proposed internal calculation, not an empirical finding or regulator-approved score.
Table 3 separates legal application dates from the status of supporting guidance and legislative proposals.
| Date | Verified event | Practical interpretation |
|---|---|---|
| 12 September 2025 | General Data Act application began. ([3]) | Assess existing access and disclosure obligations independently of the later design milestone. |
| After 12 September 2026 | Article 3(1) applies to the specified products and related services placed on the market after this date. ([71]) | Record placement facts and include access architecture in release evidence. Traficom uses the same after-date distinction. ([2]) |
| 15 May 2026 | ACM published its provisional Data Sharing Guidelines. ([15]) | Use the guidance with its stated status, rather than treating it as final legislation. |
| 21 October 2026 | The Council agreed its negotiating position on digital legislative simplification. ([12]) | Track the legislative procedure; a negotiating position is not completed enactment. ([72]) |
The design date should not be turned into a statement that all older products are outside the Data Act. Equally, a product-family development date is not the regulation’s definition of placement: the statute refers to the first making available of a connected product on the Union market. ([73])
Calculate field coverage from reader-supplied inputs
For internal measurement, define S as the approved set of in-scope field entries for one released configuration and access scenario. Count an entry as implemented only when its applicable access, metadata, permission and disclosure controls have passed the team’s review. These are proposed measurement rules.
Calculate coverage = 100 × implemented entries / entries in S. If S is empty, report “not applicable” with the scope rationale rather than dividing by zero. Count a field once in the headline ratio, and retain separate views by device configuration, user role and delivery route. The percentage multiplier is arithmetic, not a statutory threshold.
Use the following reporting controls:
- Denominator stability: Version the field set and preserve reasons for additions, exclusions and reclassification.
- Control intersection: Count a field only when all applicable controls are evidenced, rather than averaging unrelated completion percentages.
- Quality visibility: Report unavailable history, timing limitations and unresolved permission questions alongside the ratio.
- Operational evidence: Measure actual request and delivery behavior against the approved catalog; keep the event outcome available for review. ([67])
A high ratio can coexist with a missing important field or an incorrect scope decision. The proposed metric is therefore useful for finding incomplete work and showing changes over releases, while legal and safety reviews remain independent acceptance conditions.
Implications and Future Directions
Keep standards modular and legal assumptions reviewable
The recommended architecture uses interchangeable components: catalog, policy evaluation, extraction, delivery and audit. A common catalog can support several transport choices without implying that every customer must adopt the same API. DCAT addresses catalog interoperability, while OpenAPI describes HTTP interfaces; neither source establishes that its specification is mandatory under the Data Act. ([36]) ([10])
Regulatory tracking should identify what changed, its legal status and which product assumptions it affects. The Commission’s FAQ landing page identifies its published version, and the Data Act Legal Helpdesk offers direct assistance to organizations. ([74]) ([75]) The Digital Omnibus should remain a tracked change item: the Council described a negotiating mandate, and Parliament’s procedure file remained awaiting a committee decision when checked. ([12]) ([13]) Do not redesign against a proposed exception as though it were already operative.
Use a staged remediation plan
The following 30/60/90-day plan is an author-proposed work sequence. These durations are planning choices, not statutory grace periods.
- Days 1 to 30, ownership: Name accountable product, engineering, privacy, security and legal owners.
- Days 1 to 30, scope: Review product configurations, related services, placement evidence and qualified enterprise exceptions.
- Days 1 to 30, inventory: Classify fields, transformations and metadata, then map current disclosures to actual retrieval behavior.
- Days 31 to 60, access: Implement the approved direct or request-based path and recipient authorization workflow.
- Days 31 to 60, permissions: Resolve personal-data conditions and document the handling of confidentiality or safety questions.
- Days 31 to 60, evidence: Test schemas, timestamps, scope enforcement, delivery outcomes and termination.
- Days 61 to 90, integration: Exercise the complete workflow with representative user and recipient roles.
- Days 61 to 90, publication: Release accurate disclosures with the corresponding product configuration and support process.
- Days 61 to 90, review: Calculate field coverage, assign unresolved work and schedule reassessment of legal assumptions.
Keep this work within the product lifecycle. NIST’s IoT guidance explicitly spans conception, design, testing, sale and support, offering a useful international engineering reference for maintaining the resulting controls. ([76]) Privacy review should likewise extend beyond launch; the ICO’s lifecycle guidance is a comparative UK reference for that operational approach. ([57])
Conclusion
For connected medical devices, a defensible Data Act implementation connects legal scope to specific fields and working access capabilities. The design obligation applies to the relevant products and related services placed on the market after the statutory milestone, while the broader access framework has an earlier general application date. ([2]) ([3]) Product teams should preserve that distinction in release decisions and remediation plans.
The recommended operating model starts with a controlled catalog: what the product and service generate, how transformations affect classification, what metadata make the output usable, who can request access, and which delivery path fulfills the approved design. It then connects each catalog entry to permissions, disclosures, tests and evidence.
The most consequential review questions sit at the boundaries. A device user can differ from the patient whose data are represented. A technically successful transfer can still need a separate privacy assessment. An inferred score can require different treatment from its source measurements. Those distinctions should be recorded explicitly, with counsel assessing the relevant legal conclusions.
The proposed coverage calculation and remediation plan help organize the work; neither replaces that assessment. The practical outcome is a release process in which teams can demonstrate an authorized request, usable data and metadata, an accurate customer explanation, and a documented response to exceptional cases. That evidence gives product leaders a concrete basis for deciding what is ready and what still needs resolution.
About IntuitionLabs
Build practical AI for pharma and biotech with IntuitionLabs. We help life-science teams turn complex information and workflows into useful software, governed knowledge systems and AI tools.
IntuitionLabs is an AI consulting, custom software development and data engineering firm serving pharmaceutical, biotechnology, medical-device and other life-science organizations. We work with clinical, regulatory, medical-affairs, commercial, quality and IT teams to connect technology decisions with the work people need to accomplish.
AI consulting and adoption
Our AI enablement services cover readiness assessments, use-case selection, governance and policies, team workshops, adoption measurement and ongoing advisory support. We help organizations structure the information layer behind AI: source material, context, permissions and maintained knowledge that make generated answers useful and reviewable. Private LLM inference and hosted AI options support teams evaluating how to operate AI with appropriate control over their data and infrastructure.
Software, data and life-science workflows
IntuitionLabs develops custom software for pharma and biotech, integrates enterprise systems, and builds data engineering and business intelligence solutions. Areas of focus include AI agents, regulatory research, medical writing, medical affairs, CMC information, competitive intelligence and clinical-document workflows. Our eTMF intelligence work includes cross-system reconciliation and inspection-readiness support.
Enterprise platforms and regulated delivery
We provide Veeva services, application support, managed services, integrations and custom applications, alongside enterprise content work involving platforms such as Egnyte. For regulated workflows, our services include GxP enablement, computer-system validation and software development addressing 21 CFR Part 11 requirements. The applicable controls, validation responsibilities and acceptance criteria are defined for each engagement.
Work with IntuitionLabs
Explore AI enablement, pharma and biotech software development, data engineering and BI, and Veeva services. Contact IntuitionLabs to discuss your workflow, information sources and implementation needs.
IntuitionLabs publishes educational research to help life-science teams make informed technology decisions. Coverage of a product or organization does not imply a client relationship, endorsement or partnership.
Sources / 76
Need Expert Guidance on This Topic?
Let's discuss how IntuitionLabs can help you navigate the challenges covered in this article.
I'm Adrien Laurent, Founder & CEO of IntuitionLabs. With 25+ years of experience in enterprise software development, I specialize in creating custom AI solutions for the pharmaceutical and life science industries.
The information contained in this document is provided for educational and informational purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the information contained herein. Any reliance you place on such information is strictly at your own risk. In no event will IntuitionLabs.ai or its representatives be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from the use of information presented in this document. This document may contain content generated with the assistance of artificial intelligence technologies. AI-generated content may contain errors, omissions, or inaccuracies. Readers are advised to independently verify any critical information before acting upon it. All product names, logos, brands, trademarks, and registered trademarks mentioned in this document are the property of their respective owners. All company, product, and service names used in this document are for identification purposes only. Use of these names, logos, trademarks, and brands does not imply endorsement by the respective trademark holders. IntuitionLabs.ai is an AI software development company specializing in helping life-science companies implement and leverage artificial intelligence solutions. Founded in 2023 by Adrien Laurent and based in San Jose, California. This document does not constitute professional or legal advice. For specific guidance related to your business needs, please consult with appropriate qualified professionals.
Related Articles
AI Data Classification: What Is Safe for ChatGPT & Copilot
A comprehensive guide to AI data classification policies for ChatGPT, Claude, and Gemini. Learn usage limits, PII restrictions, and enterprise security risks.
Compliance Frameworks in Pharmaceutical IT: A Comparative Analysis
A detailed comparison of key compliance frameworks in pharmaceutical IT, including FDA 21 CFR Part 11, GDPR, HIPAA, and GxP, with implementation strategies and best practices.