{"id":35,"date":"2026-06-02T04:12:49","date_gmt":"2026-06-02T04:12:49","guid":{"rendered":"http:\/\/localhost:19994\/?p=35"},"modified":"2026-06-02T04:12:49","modified_gmt":"2026-06-02T04:12:49","slug":"what-counts-as-patient-pii-a-2026-compliance-guide","status":"publish","type":"post","link":"https:\/\/www.docpolish.io\/docpolish-blog\/?p=35","title":{"rendered":"What counts as patient PII: a 2026 compliance guide"},"content":{"rendered":"<h1 id=\"what-counts-as-patient-pii-a-2026-compliance-guide\">What counts as patient PII: a 2026 compliance guide<\/h1>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-33561\/1780107609860_Decorative-title-card-illustration-for-patient-PII-article.jpeg\" alt=\"Decorative title card illustration for patient PII article\"><\/p>\n<p>Patient PII is any information that can directly or indirectly identify a patient, ranging from their name and address to device identifiers, IP addresses, and dates connected to their health status. The term itself is informal. The recognised regulatory vocabulary splits into two frameworks: HIPAA\u2019s <em>protected health information<\/em> (PHI) in the United States, and GDPR\u2019s <em>personal data<\/em> in the European Union. Both frameworks govern what counts as patient PII, but they define it differently, apply different thresholds for de-identification, and carry distinct compliance obligations. For healthcare professionals, compliance officers, and legal advisors operating in 2026, understanding where these definitions align and where they diverge is not optional. A single misclassified field in a patient record can constitute a reportable breach.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-33561\/1780107592754_Healthcare-worker-reviewing-patient-records-at-desk.jpeg\" alt=\"Healthcare worker reviewing patient records at desk\"><\/p>\n<h2 id=\"what-counts-as-patient-pii-under-hipaa\">What counts as patient PII under HIPAA?<\/h2>\n<p>HIPAA does not use the term PII directly. Instead, it operationalises patient PII through the concept of <a href=\"https:\/\/medcomply.ai\/intelligence\/what-counts-as-phi\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">PHI as identifiable health information<\/a> held or transmitted by a covered entity or business associate, as defined in 45 CFR \u00a7160.103. This distinction matters because it means HIPAA compliance is not about protecting a general category of personal data. It is about protecting a specific, legally defined set of identifiers when they appear alongside health information.<\/p>\n<p>The most practical tool HIPAA provides for de-identification is the Safe Harbor method. Under Safe Harbor, 18 identifiers must be removed before a dataset can be considered de-identified and therefore outside HIPAA\u2019s scope. These identifiers include:<\/p>\n<ul>\n<li>Names<\/li>\n<li>Geographic data smaller than a state (including street address, city, county, and ZIP code)<\/li>\n<li>All dates except year (dates of birth, admission, discharge, and death)<\/li>\n<li>Telephone numbers<\/li>\n<li>Fax numbers<\/li>\n<li>Email addresses<\/li>\n<li>Social security numbers<\/li>\n<li>Medical record numbers<\/li>\n<li>Health plan beneficiary numbers<\/li>\n<li>Account numbers<\/li>\n<li>Certificate and licence numbers<\/li>\n<li>Vehicle identifiers and serial numbers<\/li>\n<li>Device identifiers and serial numbers<\/li>\n<li>Web URLs<\/li>\n<li>IP addresses<\/li>\n<li>Biometric identifiers, including fingerprints and voiceprints<\/li>\n<li>Full-face photographs and comparable images<\/li>\n<li>Any other unique identifying number or code<\/li>\n<\/ul>\n<p>The table below summarises the categories of HIPAA Safe Harbor identifiers by type, which is useful for classification exercises during data audits.<\/p>\n<table>\n<thead>\n<tr>\n<th>Category<\/th>\n<th>Examples<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Direct identifiers<\/td>\n<td>Name, social security number, medical record number<\/td>\n<\/tr>\n<tr>\n<td>Contact information<\/td>\n<td>Address, phone number, email, fax<\/td>\n<\/tr>\n<tr>\n<td>Digital identifiers<\/td>\n<td>IP address, device ID, URL<\/td>\n<\/tr>\n<tr>\n<td>Temporal identifiers<\/td>\n<td>Dates of birth, admission, discharge (except year)<\/td>\n<\/tr>\n<tr>\n<td>Biometric identifiers<\/td>\n<td>Fingerprints, voiceprints, facial photographs<\/td>\n<\/tr>\n<tr>\n<td>Geographic identifiers<\/td>\n<td>ZIP codes, street addresses, sub-state regions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>An important alternative to Safe Harbor is expert determination, where a qualified statistician assesses re-identification risk and certifies that the probability of identifying any individual is very small. This method gives organisations more flexibility but requires documented statistical justification.<\/p>\n<p><strong>Pro Tip:<\/strong> <em>When conducting a data audit, do not limit your review to structured fields in your EHR. Free-text clinical notes frequently contain dates, device references, and geographic details that qualify as PHI under HIPAA\u2019s Safe Harbor list.<\/em><\/p>\n<h2 id=\"how-does-gdpr-define-patient-personal-data\">How does GDPR define patient personal data?<\/h2>\n<p>Under GDPR, <a href=\"https:\/\/gdprlearninghub.com\/article-4-gdpr\/\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">personal data is any information relating to an identified or identifiable natural person<\/a>, as set out in Article 4. The definition is deliberately broad. Identifiability includes not just direct identifiers such as a name or national identification number, but also indirect identifiers such as location data, online identifiers, and factors specific to the physical, physiological, genetic, or mental identity of that person.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-33561\/1780108349298_Infographic-comparing-direct-and-indirect-patient-identifiers.jpeg\" alt=\"Infographic comparing direct and indirect patient identifiers\"><\/p>\n<p>For healthcare organisations operating in the EU or processing data belonging to EU residents, this has significant practical implications. Health data is classified as a special category of personal data under Article 9 GDPR, meaning it attracts a higher standard of protection and requires an explicit legal basis for processing. A clinical record that contains a patient\u2019s diagnosis alongside their postcode and date of birth is unambiguously personal data, even if the patient\u2019s name has been removed.<\/p>\n<p>GDPR also makes identifiability context-driven, which is one of its most consequential features. Information that appears anonymous in isolation can become personal data when combined with other datasets an organisation holds or could reasonably access. This is why pseudonymisation under GDPR does not equal anonymisation. Pseudonymised data remains personal data if re-identification is possible.<\/p>\n<p>Key categories of identifiers relevant to patient data under GDPR include:<\/p>\n<ul>\n<li>Name, identification number, and national health number<\/li>\n<li>Location data and IP addresses<\/li>\n<li>Cookie identifiers and device fingerprints<\/li>\n<li>Genetic and biometric data<\/li>\n<li>Health and medical information<\/li>\n<li>Data revealing racial or ethnic origin when linked to health records<\/li>\n<\/ul>\n<p><strong>Pro Tip:<\/strong> <em>If your organisation transfers patient data outside the European Economic Area, for example to a US-based cloud provider, you must have an approved transfer mechanism in place under GDPR Chapter V. Standard Contractual Clauses remain the most widely used mechanism in 2026.<\/em><\/p>\n<h2 id=\"which-indirect-identifiers-do-healthcare-professionals-overlook\">Which indirect identifiers do healthcare professionals overlook?<\/h2>\n<p>The identifiers that create the greatest compliance risk are rarely names or social security numbers. Those are obvious. The re-identification risk from indirect identifiers such as device IDs, IP addresses, admission dates, and sub-state geographic data is where most organisations are exposed.<\/p>\n<p>Consider a dataset released for research purposes. The patient\u2019s name has been removed. But the record still contains the patient\u2019s five-digit ZIP code, their date of birth, and their sex. Research by Latanya Sweeney at Carnegie Mellon University demonstrated that these three fields alone can uniquely identify a significant proportion of the US population. HIPAA\u2019s Safe Harbor requirement to truncate ZIP codes to three digits and remove all dates except year exists precisely because of this risk.<\/p>\n<p>The following scenarios illustrate how indirect identifiers create exposure in practice:<\/p>\n<ol>\n<li><strong>Device identifiers in wearable data.<\/strong> A patient\u2019s smartwatch or continuous glucose monitor transmits a unique device serial number alongside health readings. That serial number is a HIPAA identifier and must be removed or encrypted before the data is shared.<\/li>\n<li><strong>IP addresses in patient portal logs.<\/strong> When a patient logs into an online portal, their IP address is recorded. If those logs are shared with a third-party analytics provider without a business associate agreement, the IP address constitutes PHI in context.<\/li>\n<li><strong>Admission and discharge dates in research exports.<\/strong> A dataset that retains the exact date of a patient\u2019s admission to a psychiatric unit can identify the individual when combined with publicly available information about incidents at that facility on that date.<\/li>\n<li><strong>Geographic data in population health tools.<\/strong> Sub-state geographic identifiers, including census tract codes and precise GPS coordinates from mobile health applications, fall within HIPAA\u2019s Safe Harbor removal requirements.<\/li>\n<\/ol>\n<p>Partial redaction focused only on names is insufficient to achieve de-identification. Every identifier on the Safe Harbor list must be addressed collectively, not selectively.<\/p>\n<p><strong>Pro Tip:<\/strong> <em>When reviewing data exports for research or analytics, apply a linkability test. Ask whether any remaining field, alone or in combination with publicly available data, could plausibly identify a specific individual. If the answer is yes, the data is not de-identified.<\/em><\/p>\n<h2 id=\"how-do-us-state-privacy-laws-affect-patient-data-handling\">How do US state privacy laws affect patient data handling?<\/h2>\n<p>HIPAA sets a federal floor for patient data protection, but US state privacy laws frequently go further. The California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA), <a href=\"https:\/\/kukie.io\/blog\/ccpa-data-classification-personal-information\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">defines personal information across 11 categories<\/a> under Section 1798.140(v), including household-level data, device fingerprints, and behavioural data derived from browsing or purchasing activity.<\/p>\n<p>This creates a compliance gap that catches many healthcare organisations off guard. A dataset that qualifies as de-identified under HIPAA Safe Harbor may still constitute personal information under CCPA if it contains device fingerprints or inferred characteristics. The table below compares the two frameworks across key dimensions.<\/p>\n<table>\n<thead>\n<tr>\n<th>Dimension<\/th>\n<th>HIPAA PHI<\/th>\n<th>CCPA personal information<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Scope<\/td>\n<td>Health data held by covered entities<\/td>\n<td>Broad; applies to most California businesses<\/td>\n<\/tr>\n<tr>\n<td>De-identification standard<\/td>\n<td>18 Safe Harbor identifiers or expert determination<\/td>\n<td>Reasonable linkability to individual or household<\/td>\n<\/tr>\n<tr>\n<td>Household data<\/td>\n<td>Not covered<\/td>\n<td>Explicitly included<\/td>\n<\/tr>\n<tr>\n<td>Behavioural and inferred data<\/td>\n<td>Not covered<\/td>\n<td>Included (browsing history, inferences)<\/td>\n<\/tr>\n<tr>\n<td>Enforcement body<\/td>\n<td>HHS Office for Civil Rights<\/td>\n<td>California Privacy Protection Agency<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>States including Virginia (VCDPA), Colorado (CPA), and Texas (TDPSA) have enacted their own frameworks with varying definitions of personal information. For organisations managing patient data across multiple states, <a href=\"https:\/\/theaicareerlab.com\/blog\/phi-vs-pii-what-counts-as-protected-data-when-using-ai-2026\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">integrated compliance strategies<\/a> that account for HIPAA, GDPR, and state laws simultaneously are the only viable approach. Treating each regulation as a separate workstream creates gaps at the intersections.<\/p>\n<h2 id=\"how-to-protect-patient-information-in-practice\">How to protect patient information in practice<\/h2>\n<p>Protecting patient PII requires a layered approach that combines data governance, technical controls, and staff training. The following measures reflect current best practice for healthcare organisations in 2026.<\/p>\n<ul>\n<li><strong>Data mapping and classification.<\/strong> Before you can protect patient PII, you must know where it lives. Map all data flows across your systems, including EHRs, billing platforms, research databases, and third-party integrations. Classify each dataset by sensitivity and applicable regulatory framework.<\/li>\n<li><strong>De-identification and pseudonymisation.<\/strong> Apply HIPAA Safe Harbor or expert determination for US datasets. Apply pseudonymisation with appropriate technical safeguards for EU datasets, and document the pseudonymisation process to demonstrate GDPR compliance.<\/li>\n<li><strong>Technical safeguards for ePHI.<\/strong> HIPAA\u2019s Security Rule requires access controls, audit logs, integrity protections, and transmission security for electronic PHI. These are not optional configurations. They are minimum requirements.<\/li>\n<li><strong>Automated PII detection at the point of entry.<\/strong> <a href=\"https:\/\/dev.to\/heath_99ab1667dfecd3da406\/pii-redaction-for-ai-agents-why-it-cant-be-an-afterthought-46ab\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">Patient PII detection must be embedded early<\/a> in data workflows. AI models can infer identifiers from context after the fact, which means redaction applied only at the output stage is insufficient. Detection must occur at the write path.<\/li>\n<li><strong>Vendor and business associate management.<\/strong> Every third party that handles PHI on your behalf requires a signed business associate agreement under HIPAA. Review these agreements annually and verify that vendors apply equivalent de-identification standards to your own.<\/li>\n<li><strong>Breach response planning.<\/strong> Understanding <a href=\"https:\/\/fornarolegal.com\/vendor-breach-in-florida-immediate-steps-to-protect-your-business\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">your legal obligations following a vendor breach<\/a> is as important as prevention. Notification timelines under HIPAA (60 days from discovery) and GDPR (72 hours to the supervisory authority) are strict, and non-compliance compounds the original breach.<\/li>\n<\/ul>\n<p><strong>Pro Tip:<\/strong> <em>When deploying AI tools that process patient documents, verify that PII detection and redaction occur client-side or before data reaches the AI model. Tools that send raw patient documents to an external AI engine without prior anonymisation create a compliance exposure that no contractual safeguard fully eliminates. You can read more about <a href=\"https:\/\/www.docpolish.io\/docpolish-blog\/reduce-data-breach-risk-in-document-handling\" target=\"_blank\" rel=\"noopener\">reducing data breach risk<\/a> in document workflows.<\/em><\/p>\n<h2 id=\"the-compliance-challenge-no-one-talks-about-enough\">The compliance challenge no one talks about enough<\/h2>\n<p>I have spent years reviewing how healthcare organisations approach patient PII, and the pattern I see most consistently is this: organisations invest heavily in perimeter security and almost nothing in data classification. They know their firewall is configured correctly. They have no idea whether their research exports contain residual ZIP codes or admission dates that breach Safe Harbor.<\/p>\n<p>The emergence of AI in clinical workflows has made this worse, not better. AI agents can infer identifiers from context that appears innocuous in isolation. A model trained on clinical notes can reconstruct patient identity from writing style, treatment patterns, and temporal references, even after names have been removed. Governance requirements follow identifiable data wherever it exists, and that principle now extends to inferred identifiers.<\/p>\n<p>My view is that the organisations managing patient PII well in 2026 are those that have stopped treating HIPAA, GDPR, and state laws as separate compliance projects. They have built a single data governance framework that maps each data element to its applicable regulatory obligations, and they apply the most stringent standard by default. That approach costs more to implement. It costs far less than a breach notification exercise, a regulatory investigation, or the <a href=\"https:\/\/fornarolegal.com\/protecting-data-what-are-the-requirements-and-consequences-for-my-business\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">legal consequences of inadequate data protection<\/a>.<\/p>\n<p>The other shift I would advocate for is continuous training, not annual tick-box exercises. The definition of what counts as patient PII is not static. State laws are expanding. AI inference capabilities are advancing. The compliance officer who understood the 18 Safe Harbor identifiers in 2020 needs to understand device fingerprints, inferred health characteristics, and cross-border pseudonymisation requirements in 2026. That requires ongoing education, not a once-yearly module.<\/p>\n<h2 id=\"how-docpolish-helps-you-handle-patient-documents-safely\">How Docpolish helps you handle patient documents safely<\/h2>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-33561\/1779795678885_docpolish.jpg\" alt=\"https:\/\/www.docpolish.io\/\"><\/p>\n<p>Docpolish is built for exactly the compliance challenge described above. When you process patient documents through Docpolish, PII detection and anonymisation occur entirely within your browser before any content reaches an AI engine. The original identifiers are restored in the final output, meaning your documents are polished without your patient data ever leaving your control. Every processed document receives a trust identifier, creating an audit trail that satisfies HIPAA and GDPR accountability requirements. For healthcare organisations that need <a href=\"https:\/\/www.docpolish.io\/\" target=\"_blank\" rel=\"noopener\">AI-powered document refinement<\/a> without the compliance exposure of sending raw patient data to an external model, Docpolish provides a privacy-first alternative that is built for regulated industries.<\/p>\n<h2 id=\"faq\">FAQ<\/h2>\n<h3 id=\"what-is-the-difference-between-patient-pii-and-phi\">What is the difference between patient PII and PHI?<\/h3>\n<p>Patient PII is an informal term for any information that can identify a patient. PHI is the legally defined term under HIPAA, referring specifically to identifiable health information held by a covered entity or business associate. All PHI is patient PII, but not all patient PII qualifies as PHI under HIPAA\u2019s specific criteria.<\/p>\n<h3 id=\"what-are-the-18-hipaa-safe-harbor-identifiers\">What are the 18 HIPAA Safe Harbor identifiers?<\/h3>\n<p>The 18 identifiers include names, geographic data smaller than a state, all dates except year, phone numbers, fax numbers, email addresses, social security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate and licence numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code.<\/p>\n<h3 id=\"does-removing-a-patients-name-make-their-data-de-identified\">Does removing a patient\u2019s name make their data de-identified?<\/h3>\n<p>No. Partial redaction of names alone is insufficient. All 18 Safe Harbor identifiers must be removed for a dataset to qualify as de-identified under HIPAA. Residual fields such as ZIP codes, dates, and device IDs can still enable re-identification.<\/p>\n<h3 id=\"does-gdpr-apply-to-uk-healthcare-organisations-after-brexit\">Does GDPR apply to UK healthcare organisations after Brexit?<\/h3>\n<p>UK healthcare organisations are subject to the UK GDPR, which mirrors the EU GDPR but is administered by the Information Commissioner\u2019s Office rather than EU supervisory authorities. The substantive definition of personal data and the obligations around health data processing are equivalent.<\/p>\n<h3 id=\"what-counts-as-patient-pii-under-ccpa\">What counts as patient PII under CCPA?<\/h3>\n<p>Under CCPA, patient PII includes any information that can reasonably be linked to an individual or household, covering device fingerprints, behavioural data, location information, and inferred characteristics. This definition is broader than HIPAA PHI and can apply to datasets that HIPAA considers de-identified.<\/p>\n<hr>\n<h2 id=\"key-takeaways\">Key takeaways<\/h2>\n<p>Patient PII spans direct identifiers, indirect quasi-identifiers, and inferred characteristics, and no single regulatory framework captures all of them, making a unified compliance approach the only reliable protection.<\/p>\n<table>\n<thead>\n<tr>\n<th>Point<\/th>\n<th>Details<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>HIPAA uses PHI, not PII<\/td>\n<td>HIPAA operationalises patient PII through PHI and 18 Safe Harbor identifiers, not a standalone PII definition.<\/td>\n<\/tr>\n<tr>\n<td>GDPR is context-driven<\/td>\n<td>Under GDPR, data becomes personal when re-identification is possible, even if names are absent.<\/td>\n<\/tr>\n<tr>\n<td>Indirect identifiers carry real risk<\/td>\n<td>Device IDs, IP addresses, and admission dates can identify patients when combined with other data.<\/td>\n<\/tr>\n<tr>\n<td>State laws go further than HIPAA<\/td>\n<td>CCPA and similar laws cover household data, device fingerprints, and behavioural data outside HIPAA\u2019s scope.<\/td>\n<\/tr>\n<tr>\n<td>Detection must happen at the source<\/td>\n<td>AI-assisted PII redaction applied only at output stage is insufficient; detection must occur at the point of data entry.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2 id=\"recommended\">Recommended<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.docpolish.io\/docpolish-blog\/how-underwriting-document-handling-works-in-2026\" target=\"_blank\" rel=\"noopener\">DocPolish Insights<\/a><\/li>\n<li><a href=\"https:\/\/www.docpolish.io\/docpolish-blog\/ai-document-review-benefits-for-law-firms-in-2026\" target=\"_blank\" rel=\"noopener\">DocPolish Insights<\/a><\/li>\n<li><a href=\"https:\/\/www.docpolish.io\/docpolish-blog\/reduce-data-breach-risk-in-document-handling\" target=\"_blank\" rel=\"noopener\">DocPolish Insights<\/a><\/li>\n<li><a href=\"https:\/\/www.docpolish.io\/\" target=\"_blank\" rel=\"noopener\">DocPolish | Intelligent Document Refinement<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Discover what counts as patient PII in our 2026 compliance guide. Stay informed on HIPAA and GDPR definitions to avoid costly breaches!<\/p>\n","protected":false},"author":1,"featured_media":36,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[102,100,103,104,99,101],"class_list":["post-35","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-examples-of-patient-pii","tag-how-to-protect-patient-information","tag-importance-of-patient-pii","tag-patient-identifiers-explained","tag-what-counts-as-patient-pii","tag-what-is-patient-pii"],"_links":{"self":[{"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=\/wp\/v2\/posts\/35","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=35"}],"version-history":[{"count":0,"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=\/wp\/v2\/posts\/35\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=\/wp\/v2\/media\/36"}],"wp:attachment":[{"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=35"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=35"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.docpolish.io\/docpolish-blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=35"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}