{"id":24993,"date":"2023-10-23T05:00:00","date_gmt":"2023-10-23T03:00:00","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=24993&#038;category=hard-development"},"modified":"2023-10-23T11:32:52","modified_gmt":"2023-10-23T09:32:52","slug":"the-importance-of-traceability-from-the-perspective-of-designing-a-medical-device-software","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/en\/the-importance-of-traceability-from-the-perspective-of-designing-a-medical-device-software\/","title":{"rendered":"The importance of traceability from the perspective of designing a medical device software"},"content":{"rendered":"\n<p>When designing a new product for the regulated environment, each manufacturer meets the challenge to provide compliance with multiple standards and regulations to achieve the certification required to release a product on the market. Therefore, he needs to ensure notified body that the device is safe and works as intended. Experience suggests that <strong>well-prepared documentation<\/strong> during the design process is a key factor in achieving this goal.<\/p>\n\n\n\n<p>In the process of designing the product, some documentation path that leads from input parameters to specific design decisions at each sub-stage should be created. This kind of process is nothing more like the basis for maintaining product traceability.<\/p>\n\n\n\n<p>When learning about any design process, you may hear about traceability and its importance in Quality Management System (QMS). This article describes the use of this term in one of the most regulated environments &#8211; medical device software design.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Traceability in general<\/strong><\/h2>\n\n\n\n<p>There are plenty of definitions of traceability in literature. The one that accurately captures its meaning is:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><\/p>\n<cite><em><em>Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction (i.e., from its origins through its development and specification to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases)<\/em> <strong><a id=\"_ftnref1\" href=\"#_ftn1\" class=\"ek-link\" rel=\"nofollow\" >[1]<\/a><\/strong><\/em><br><\/cite><\/blockquote>\n\n\n\n<p>In other words, in the term \u2018Traceability\u2019 two simple words are hidden \u2013 \u201ctrace\u201d and \u201cability\u201d. This combination may mean <strong>the product&#8217;s ability to trace the history of the requirements specified for that product.<\/strong><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong><strong>Traceability in the medical device domain<\/strong><\/strong><\/h2>\n\n\n\n<p>The main standard that specifically addresses the requirements for the traceability of medical devices is ISO 13485. In the product realization chapter, the following can be found:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><\/p>\n<cite><em><em>The organization shall document procedures for traceability. These procedures shall define the extent of traceability in accordance with applicable regulatory requirements and the records to be maintained<\/em> <a href=\"https:\/\/sii.pl\/blog\/wp-admin\/post.php?post=24962&amp;action=edit#_ftn1\"><strong>[<\/strong><\/a><strong><a href=\"https:\/\/sii.pl\/blog\/wp-admin\/post.php?post=24962&amp;action=edit#_ftn1\">2<\/a><\/strong><a href=\"https:\/\/sii.pl\/blog\/wp-admin\/post.php?post=24962&amp;action=edit#_ftn1\"><strong>]<\/strong><\/a><\/em><\/cite><\/blockquote>\n\n\n\n<p>Traceability shall accompany the main stages of medical device realization, especially including the product implementation plan or design and development plan. However, it is worth mentioning that ISO 13485 does not describe the specific methods or technologies to be used, but defines general requirements for traceability. The way a medical device is tracked may vary depending on many factors, like the type of device, intended use, or regulatory jurisdiction.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Standards, guidelines, and regulations<\/strong><\/h3>\n\n\n\n<p>In addition to ISO 13485, other standards, guidelines, and regulations, for example: <a><\/a><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ISO 14971,<\/li>\n\n\n\n<li>U.S. Food and Drug Administration\u2019s (FDA) guidance \u201cGeneral Principles of Software Validation<\/li>\n\n\n\n<li>European Medical Device Regulation (MDR),<\/li>\n<\/ul>\n\n\n\n<p>also address traceability within broader medical device requirements. It would be difficult to include them all in one article.<\/p>\n\n\n\n<p>Generally speaking, to comply with traceability requirements and recommendations, <strong>the manufacturer has to address applicable standards and regulation<\/strong>s specific to the region and type of device produced.<\/p>\n\n\n\n<p><a aria-label=\" (opens in a new tab)\" href=\"https:\/\/sii.pl\/blog\/en\/search\/IEC%2062304\/\" target=\"_blank\" rel=\"noreferrer noopener\" class=\"ek-link\">The IEC 62304 standard, which has already been blogged<\/a> about, defines the medical device software life cycle process. Traceability in the context of this standard is the heart of our case. The IEC 62304 sets out the requirements for the development and maintenance of medical device software. The development part consists of some stages, further described in Fig. 1 (the software is named \u201cSW\u201d). In conjunction with other standards, in particular ISO 13485 and ISO 14971, it addresses the issues of safety and effectiveness.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>The role of traceability<\/strong><\/h3>\n\n\n\n<p>The role of traceability in this standard is explained as a:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><\/p>\n<cite><em>degree to which a relationship can be established between two or more products of the development PROCESS,<\/em><\/cite><\/blockquote>\n\n\n\n<p>and begins in chapter 5 of this standard called Software Development Process. Its steps 5.1 to 5.8 are shown in the diagram below:<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/1.jpg\"><img decoding=\"async\" width=\"1024\" height=\"569\" src=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/1-1024x569.jpg\" alt=\"Software Development Process\" class=\"wp-image-24971\" srcset=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/1-1024x569.jpg 1024w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/1-300x167.jpg 300w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/1-768x427.jpg 768w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/1.jpg 1165w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><figcaption class=\"wp-element-caption\">Fig. 1 Software Development Process<\/figcaption><\/figure>\n\n\n\n<p>Table 1 presents areas where Traceability is pointed out as required (\u201cshall\u201d narration) or recommended (\u201ccan\u201cnarration). Traceability Context Description specifies what path is to be traced in the prism of Traceability for the specific step of the process.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td class=\"has-text-align-center\" data-align=\"center\"><strong>IEC 62304 chapter<\/strong><strong><\/strong><\/td><td class=\"has-text-align-center\" data-align=\"center\"><strong>Traceability Context Description<\/strong><strong><\/strong><\/td><\/tr><tr><td class=\"has-text-align-center\" data-align=\"center\">5.1.1 Software Development Plan<\/td><td class=\"has-text-align-center\" data-align=\"center\">Relations between System requirements, Software Requirements, Software System Test, RISK CONTROL measures implemented in software <strong>shall<\/strong> be planned to be tracked down via traceability<\/td><\/tr><tr><td class=\"has-text-align-center\" data-align=\"center\">5.2.6 Verify Software requirements<\/td><td class=\"has-text-align-center\" data-align=\"center\">Relation between software requirements and system requirements <strong>shall<\/strong> be verified via Traceability<\/td><\/tr><tr><td class=\"has-text-align-center\" data-align=\"center\">5.3.6 Verify software ARCHITECTURE<\/td><td class=\"has-text-align-center\" data-align=\"center\">The software ARCHITECTURE and software requirements, also RISK CONTROL related, <strong>can<\/strong> be verified via Traceability analysis<\/td><\/tr><tr><td class=\"has-text-align-center\" data-align=\"center\">5.4.4 Verify detailed design<\/td><td class=\"has-text-align-center\" data-align=\"center\">Tracking the implementation of software architecture through software detailed design can be done through traceability<\/td><\/tr><tr><td class=\"has-text-align-center\" data-align=\"center\">5.7.4 Evaluate SOFTWARE SYSTEM testing<\/td><td class=\"has-text-align-center\" data-align=\"center\">Relation between software requirements and Test\/Verification documentation <strong>shall<\/strong> be shown out via traceability<\/td><\/tr><tr><td class=\"has-text-align-center\" data-align=\"center\">7.3.3 Document TRACEABILITY<\/td><td class=\"has-text-align-center\" data-align=\"center\">Traceability of software HAZARDS <strong>shall<\/strong> be recorded in the flow: hazardous situation, software item, software cause, RCM (Risk Control Measure) and Verification of RCM<\/td><\/tr><tr><td class=\"has-text-align-center\" data-align=\"center\">8.2.4 Provide means for TRACEABILITY of change<\/td><td class=\"has-text-align-center\" data-align=\"center\">Traceability <strong>shall<\/strong> be maintained for change control process between change request, relevant problem report and approval of change request<\/td><\/tr><tr><td class=\"has-text-align-center\" data-align=\"center\">B.5.2 Software requirement analysis<\/td><td class=\"has-text-align-center\" data-align=\"center\">The mean of traceability in software requirement analysis phase is emphasized<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\">Tab. 1 References to traceability in IEC 62304<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>V-model<\/strong><\/h3>\n\n\n\n<p>The role of traceability in the software life-cycle process can be described using the V-model illustrated in Fig. 2. Traceability always accompanies the verification of requirements defined at individual stages of the process. The green area of the figure represents IEC 62304 scope.<\/p>\n\n\n\n<p>Where does V-model come from and what does it show? IEC 60601-1 standard is the source. It describes Programmable Electrical Medical System (PEMS) development and is related to the software life-cycle process.<\/p>\n\n\n\n<p>Within the green area in Fig. 2, the IEC 62304 requirements apply to IEC 60601-1 at the PEMS component level. From the point of specifying software requirements to software integration, the software system is being established. Going forward, the software system belongs to the programmable electrical subsystem (PESS) that is a part of PEMS.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-full\"><a href=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/Diagram-V-model.png\"><img decoding=\"async\" width=\"1009\" height=\"628\" src=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/Diagram-V-model.png\" alt=\"PEMS development life-cycle model\" class=\"wp-image-24975\" srcset=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/Diagram-V-model.png 1009w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/Diagram-V-model-300x187.png 300w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/Diagram-V-model-768x478.png 768w\" sizes=\"(max-width: 1009px) 100vw, 1009px\" \/><\/a><figcaption class=\"wp-element-caption\">Ryc. 2 PEMS development life-cycle model<\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>A little bit of practice<\/strong><\/h2>\n\n\n\n<p>How to move forward from being aware of tracking every step of the design inputs and outputs that define the product to creating a traceability analysis for a medical equipment software system? It is worth starting by collecting traceability deliverables.<\/p>\n\n\n\n<p>These can be:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Stakeholder Requirements \u2013 they describe what the system will do for the specific environment from the stakeholder\u2019s (patients, physicians, service, employers, business owners etc.) point of view and refer to the origin of the requirements, e.g., overview of similar products, service feedback, intended use or actual input from users (user needs\/marketing input).<\/li>\n\n\n\n<li>System Requirements \u2013 define the system\u2019s features, attributes, functional and performance requirements in a measurable way to satisfy stakeholder requirements, regulatory requirements, and risk analysis (RCMs), its input may also come from e.g., already established requirements from similar products or usability studies.<\/li>\n\n\n\n<li>Subsystem Requirements \u2013 if the system is divided into subsystems, they refer to system requirements, system architecture, risk analysis, and other sources, e.g., usability studies; can be called system requirements for a specific subsystem.<\/li>\n<\/ul>\n\n\n\n<p>Based on these inputs, a path of requirements from stakeholders to the component level is formed via traceability.<\/p>\n\n\n\n<p>The next step is to decide how many levels we want to maintain in one traceability analysis. That is, whether we prefer to represent a full range of this path in one document or divide it into several records. There are no specific requirements or restrictions on how much we should include in one document. The penultimate aspect is &#8211; in what form we want to present traceability. The most common is a traceability matrix. Putting this into exemplary practice, a sample matrix pattern for subsystem-level requirements is presented below:<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.1.jpg\"><img decoding=\"async\" width=\"1024\" height=\"88\" src=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.1-1024x88.jpg\" alt=\"Subsystem requirements traceability matrix template\" class=\"wp-image-24978\" srcset=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.1-1024x88.jpg 1024w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.1-300x26.jpg 300w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.1-768x66.jpg 768w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.1.jpg 1164w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><figcaption class=\"wp-element-caption\">Tab. 2 Subsystem requirements traceability matrix template<\/figcaption><\/figure>\n\n\n\n<p>Finally, it must be confirmed that the outputs meet specified requirements through V&amp;V activities (Verification and Validation). All requirements must be covered by verification and\/or validation, the results of which are fed into the traceability matrix. <\/p>\n\n\n\n<p>Example below (SRS \u2013 Software Requirement Specification, SR \u2013 System Requirement, STP \u2013 System Test Protocol, STR \u2013 System Test Report, Ver \u2013 Verification, Val \u2013 Validation):<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.3.jpg\"><img decoding=\"async\" width=\"1024\" height=\"155\" src=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.3-1024x155.jpg\" alt=\"Szablon macierzy identyfikowalno\u015bci wymaga\u0144 podsystemu z uwzgl\u0119dnion\u0105 weryfikacj\u0105 i walidacj\u0105\" class=\"wp-image-24982\" srcset=\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.3-1024x155.jpg 1024w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.3-300x46.jpg 300w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.3-768x117.jpg 768w, https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/t.3.jpg 1159w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><figcaption class=\"wp-element-caption\">Tab. 3 Subsystem requirements traceability matrix template with Verification and Validation included<\/figcaption><\/figure>\n\n\n\n<p>The solution above should be considered only as an example. Its structure and content may vary depending on the type and individual needs of the project. e.g., it could be reasonable to omit the validation step altogether.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What makes it so important?<\/strong><\/h2>\n\n\n\n<p>Tracking the list of requirements in a compiled form can show us yet undiscovered missing or incomplete requirements. Moreover, it can highlight whether all requirements have been sufficiently verified.<\/p>\n\n\n\n<p>Traceability can also be helpful in making decisions during product development. You could assess the impact of requirements on the product\u2019s design. And in case of any change of requirements, you will be able to analyze its influence on the entire development process.<\/p>\n\n\n\n<p>Traceability proves valuable in project management as it provides <strong>a clear measure of progress<\/strong>. By associating requirements with tests, it helps to control the scope and realistically approach the fulfillment of these requirements, taking into account the available time frames.<\/p>\n\n\n\n<p>Finally, all of the above comes down to ensuring high quality and safety.<\/p>\n\n\n\n<p>Practically most of the activities and tasks within the software development process are aimed at:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>reducing the risk that the use of the software may potentially lead to,<\/li>\n\n\n\n<li>improving and maintaining the quality of the software.<\/li>\n<\/ul>\n\n\n\n<p>It should be noted that in IEC 62304, risk and quality management are constant companions throughout the whole lifecycle model (Fig. 1 and Fig. 2).<\/p>\n\n\n\n<p>In all, traceability appears as a tool that:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>can control that risk, by tracing RCMs to the software requirements, software requirements to the software system, completing this chain in unit and integration tests,<\/li>\n\n\n\n<li>is the guardian of quality control in the face of product growth, ensuring that the quality requirements of the system are met via the V&amp;V phase, documenting proper implementation and the extent to which test cases test these requirements.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Summary<\/strong><\/h2>\n\n\n\n<p>Demonstrating a product\u2019s safety and effectiveness is the bottom line to achieving conformance to specific regulations or standards. Handing well traced documents to notification\u2019s body, product certification is almost at your fingertips.<\/p>\n\n\n\n<p>Just as there is no clear development path for each medical device, it is difficult to find a single solution for determining its traceability. Readers who have similar thoughts and feel lost in the fog are welcome to contact us. A team of experienced Sii engineers supports not only the creation of this type of documentation but also testing, certification, and more.<\/p>\n\n\n\n<p>***<\/p>\n\n\n\n<p><a href=\"https:\/\/sii.pl\/blog\/wp-admin\/post.php?post=24962&amp;action=edit#_ftnref1\" class=\"ek-link\">[1]<\/a> O.C.Z. Gotel, C.W. Finkelstein, <a href=\"https:\/\/ieeexplore.ieee.org\/document\/292398\" target=\"_blank\" aria-label=\"An analysis of the requirements traceability problem (opens in a new tab)\" rel=\"noreferrer noopener\" class=\"ek-link\" rel=\"nofollow\" >An analysis of the requirements traceability problem<\/a>, in: Requirements Engineering, 1994., Proceedings of the First International Conference on Requirements Engineering, 1994, pp. 94-101<\/p>\n\n\n\n<p><a href=\"https:\/\/sii.pl\/blog\/wp-admin\/post.php?post=24962&amp;action=edit#_ftnref1\">[2]<\/a> ISO 13485:2016 &#8211; Medical devices \u2014 Quality management systems \u2014 Requirements for regulatory purposes <\/p>\n\n\n<div class=\"kk-star-ratings kksr-auto kksr-align-left kksr-valign-bottom\"\n    data-payload='{&quot;align&quot;:&quot;left&quot;,&quot;id&quot;:&quot;24993&quot;,&quot;slug&quot;:&quot;default&quot;,&quot;valign&quot;:&quot;bottom&quot;,&quot;ignore&quot;:&quot;&quot;,&quot;reference&quot;:&quot;auto&quot;,&quot;class&quot;:&quot;&quot;,&quot;count&quot;:&quot;6&quot;,&quot;legendonly&quot;:&quot;&quot;,&quot;readonly&quot;:&quot;&quot;,&quot;score&quot;:&quot;5&quot;,&quot;starsonly&quot;:&quot;&quot;,&quot;best&quot;:&quot;5&quot;,&quot;gap&quot;:&quot;11&quot;,&quot;greet&quot;:&quot;&quot;,&quot;legend&quot;:&quot;5\\\/5 ( votes: 6)&quot;,&quot;size&quot;:&quot;18&quot;,&quot;title&quot;:&quot;The importance of traceability from the perspective of designing a medical device software&quot;,&quot;width&quot;:&quot;139.5&quot;,&quot;_legend&quot;:&quot;{score}\\\/{best} ( {votes}: {count})&quot;,&quot;font_factor&quot;:&quot;1.25&quot;}'>\n            \n<div class=\"kksr-stars\">\n    \n<div class=\"kksr-stars-inactive\">\n            <div class=\"kksr-star\" data-star=\"1\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" data-star=\"2\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" data-star=\"3\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" data-star=\"4\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" data-star=\"5\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n    <\/div>\n    \n<div class=\"kksr-stars-active\" style=\"width: 139.5px;\">\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n    <\/div>\n<\/div>\n                \n\n<div class=\"kksr-legend\" style=\"font-size: 14.4px;\">\n            5\/5 ( votes: 6)    <\/div>\n    <\/div>\n","protected":false},"excerpt":{"rendered":"<p>When designing a new product for the regulated environment, each manufacturer meets the challenge to provide compliance with multiple standards &hellip; <a class=\"continued-btn\" href=\"https:\/\/sii.pl\/blog\/en\/the-importance-of-traceability-from-the-perspective-of-designing-a-medical-device-software\/\">Continued<\/a><\/p>\n","protected":false},"author":575,"featured_media":24988,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","inline_featured_image":false,"footnotes":""},"categories":[1320],"tags":[1817,1655,1622,1505,1336],"class_list":["post-24993","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hard-development","tag-iso-en","tag-cybersecurity-en-2","tag-medical-devices","tag-healthcare-2","tag-cybersecurity-en"],"acf":[],"aioseo_notices":[],"republish_history":[],"featured_media_url":"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/Znaczenie-identyfikowalnosci-z-perspektywy-projektowania-oprogramowania-wyrobu-medycznego.jpg","category_names":["Hard development"],"_links":{"self":[{"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/posts\/24993"}],"collection":[{"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/users\/575"}],"replies":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/comments?post=24993"}],"version-history":[{"count":1,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/posts\/24993\/revisions"}],"predecessor-version":[{"id":24995,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/posts\/24993\/revisions\/24995"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/media\/24988"}],"wp:attachment":[{"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/media?parent=24993"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/categories?post=24993"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sii.pl\/blog\/en\/wp-json\/wp\/v2\/tags?post=24993"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}