Bệnh án điện tử FHIR tại Việt Nam (TT 13/2025/TT-BYT)

1. TT 13/2025 — yêu cầu chính cho bệnh án điện tử FHIR

Thông tư 13/2025/TT-BYT ban hành ngày 06/6/2025, hiệu lực 21/7/2025, thay thế Thông tư 46/2018 về bệnh án điện tử. Văn bản này đặt nền tảng cho làn sóng triển khai EMR mới và là động lực chính khiến nhiều bệnh viện cần đến FHIR — chuẩn dữ liệu liên thông quốc tế đã được HL7 phát triển cho mục tiêu trao đổi dữ liệu lâm sàng giữa các hệ thống khác nhau.

Yêu cầu cốt lõi của Thông tư là: bệnh án điện tử phải kết nối với số định danh cá nhân hoặc tài khoản định danh điện tử VNeID, phải đảm bảo hạ tầng bảo mật và phục hồi dữ liệu, phải tuân thủ NĐ 137/2024 về giao dịch điện tử và chữ ký số, phải truy xuất được dữ liệu khi cơ quan có thẩm quyền yêu cầu, và phải tuân thủ Luật Khám bệnh, chữa bệnh 2023 về phạm vi hành nghề.

Lộ trình deadline cụ thể

Yêu cầu ánh xạ sang FHIR

2. Kiến trúc FHIR cho EMR

FHIR không thay thế hệ thống EMR sẵn có. FHIR là lớp giao tiếp đặt phía trên kho dữ liệu lâm sàng, cho phép EMR hiện hữu trao đổi dữ liệu với VNeID, cổng BHXH, hệ thống xét nghiệm, và các bệnh viện khác theo một ngôn ngữ chung. Cách tiếp cận này giúp bệnh viện không phải viết lại EMR từ đầu, đồng thời mở ra khả năng tích hợp lâu dài.

Sơ đồ dưới đây mô tả vị trí của FHIR server giữa giao diện EMR và các hệ thống bên ngoài. Lưu ý VNeID nằm ở lớp xác thực và định danh, không nằm trong Patient.identifier của FHIR.

┌─────────────────────────────────────────────────┐
│ Giao diện EMR (bác sĩ, điều dưỡng nhập liệu)    │
└─────────────────────────────────────────────────┘
                     │ FHIR REST
                     ↓
┌─────────────────────────────────────────────────┐
│ FHIR Server (HAPI / Microsoft / Google / ...)   │
│  - Patient, Encounter, Composition              │
│  - Condition, Observation, Procedure            │
│  - MedicationRequest, AllergyIntolerance        │
│  - DocumentReference (PDF lưu trữ)              │
│  - Provenance, AuditEvent, Consent              │
└─────────────────────────────────────────────────┘
         │                        │
         │ Tích hợp                │ FHIR API
         ↓                        ↓
┌──────────────┐          ┌──────────────┐
│ VNeID        │          │ Cổng BHXH    │
│ auth/định    │          │ (Claim,      │
│ danh         │          │  XML 4210)   │
└──────────────┘          └──────────────┘

Bệnh viện có thể chọn FHIR server mã nguồn mở như HAPI FHIR, hoặc dịch vụ quản trị từ Microsoft Azure API for FHIR và Google Cloud Healthcare API. Lựa chọn phụ thuộc quy mô, kỹ năng đội ngũ và chính sách lưu trữ dữ liệu trong nước theo Luật An ninh mạng.

3. Cấu trúc bệnh án điện tử ánh xạ FHIR Composition

Composition là Resource đóng vai trò header của bệnh án. Một Composition gồm metadata (loại tài liệu, bệnh nhân, ca khám, ngày, tác giả, tiêu đề, người chứng thực) cùng danh sách section trỏ tới các Resource lâm sàng khác. Khi kết hợp với Bundle kiểu document, Composition tạo ra một tài liệu y tế đóng gói có chữ ký, sẵn sàng trao đổi giữa các hệ thống.

Ví dụ dưới đây mô tả bệnh án nội trú khoa Tim mạch của bệnh nhân Nguyễn Thị Lan tại Bệnh viện Bạch Mai, do BS Trần Văn Minh chứng thực. Mọi trường bắt buộc của Composition R4 đều có mặt: status, type, subject, date, author và title. Mỗi section chứa text dạng Narrative với status và div để giúp tài liệu tự đọc được khi xem trong viewer FHIR thông thường.

{
  "resourceType": "Composition",
  "id": "comp-bm-001",
  "status": "final",
  "type": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "11503-0",
      "display": "Medical records"
    }]
  },
  "subject": { "reference": "Patient/nguyen-thi-lan" },
  "encounter": { "reference": "Encounter/enc-tim-mach-001" },
  "date": "2026-04-30T17:00:00+07:00",
  "author": [{ "reference": "Practitioner/bs-tran-van-minh" }],
  "title": "Bệnh án nội trú — Khoa Tim mạch — BV Bạch Mai",
  "attester": [{
    "mode": "professional",
    "time": "2026-04-30T17:00:00+07:00",
    "party": { "reference": "Practitioner/bs-tran-van-minh" }
  }],
  "custodian": { "reference": "Organization/bv-bach-mai" },
  "section": [
    {
      "title": "Hành chính",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Bệnh nhân Nguyễn Thị Lan, nhập viện 28/4/2026.</div>"
      },
      "entry": [
        { "reference": "Patient/nguyen-thi-lan" },
        { "reference": "Encounter/enc-tim-mach-001" }
      ]
    },
    {
      "title": "Tiền sử",
      "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Tăng huyết áp 5 năm; dị ứng penicillin.</div>"
      },
      "entry": [
        { "reference": "Condition/tha-001" },
        { "reference": "AllergyIntolerance/aller-pcn-001" }
      ]
    },
    {
      "title": "Khám lâm sàng",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "ClinicalImpression/ci-tm-001" }]
    },
    {
      "title": "Cận lâm sàng",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "DiagnosticReport/ecg-001" }]
    },
    {
      "title": "Chẩn đoán",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "Condition/dx-i10" }]
    },
    {
      "title": "Điều trị",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "MedicationRequest/mr-001" }]
    },
    {
      "title": "Tổng kết",
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">...</div>" },
      "entry": [{ "reference": "Observation/summary-001" }]
    }
  ]
}

Với cấu trúc này, hệ thống nhận tài liệu có thể đọc tóm tắt từ section.text ngay cả khi chưa hỗ trợ đầy đủ các Resource liên kết. Khi cần kiểm chứng dữ liệu, hệ thống đi tiếp xuống entry để lấy Resource cấu trúc.

4. 8 thành phần bắt buộc của bệnh án ánh xạ FHIR Resource

Mẫu bệnh án theo TT 13/2025 và các thông tư hướng dẫn của Bộ Y tế gồm 8 phần chính. Mỗi phần ánh xạ sang một hoặc một nhóm Resource FHIR cụ thể. Phần này mô tả chi tiết từng thành phần, kèm Resource tương ứng và chú thích quan trọng về terminology Việt Nam.

4.1 Hành chính

Resource chính là Patient (theo profile VNCorePatient) và Encounter. VNCorePatient bắt buộc CCCD là định danh chính, kèm các slice tùy chọn cho BHYT, BHXH, GKS (giấy khai sinh, dùng cho trẻ chưa có CCCD), HC (hộ chiếu, dùng cho người nước ngoài), và MRN nội bộ bệnh viện. Lưu ý quan trọng: VNeID không nằm trong Patient.identifier. Quan hệ giữa bệnh án và VNeID được ghi nhận ở lớp xác thực, ngoài Resource Patient, và lưu vết qua AuditEvent/Provenance.

Encounter mô tả lượt khám hoặc nhập viện: thời điểm bắt đầu và kết thúc, loại lượt (ngoại trú, nội trú, cấp cứu), khoa phòng phụ trách, lý do nhập viện. Với bệnh nhân BHYT, Encounter cần kèm extension cho tuyến KCB và loại KCB BHYT.

4.2 Tiền sử

Phần tiền sử dùng Condition với clinicalStatus = inactive hoặc resolved để biểu diễn bệnh sử cũ, AllergyIntolerance để ghi nhận dị ứng thuốc và thực phẩm, và FamilyMemberHistory cho tiền sử gia đình. Mã chẩn đoán tiền sử dùng ICD-10 VN theo QĐ 4469/QĐ-BYT (28/10/2020) cùng các bổ sung sau đó.

4.3 Khám lâm sàng

ClinicalImpression ghi nhận đánh giá tổng quát của bác sĩ sau thăm khám. Sinh hiệu (mạch, huyết áp, SpO2, nhiệt độ, nhịp thở) ghi bằng Observation với mã LOINC chuẩn. Kết quả khám theo cơ quan (tim mạch, hô hấp, tiêu hoá, thần kinh) cũng dùng Observation, có thể nhóm bằng Observation kiểu panel.

4.4 Cận lâm sàng

Kết quả xét nghiệm máu, nước tiểu và sinh hoá dùng Observation, bind tới LOINC kết hợp với danh mục mã chỉ số cận lâm sàng theo QĐ 1227/QĐ-BYT (đợt 1, 11/4/2025) gồm 2.964 chỉ số huyết học, sinh hoá, vi sinh, giải phẫu bệnh và chẩn đoán hình ảnh. DiagnosticReport đóng gói kết quả tổng hợp của một xét nghiệm hoặc một báo cáo chẩn đoán hình ảnh. ImagingStudy trỏ tới hệ thống PACS để lấy hình ảnh DICOM thực tế.

4.5 Chẩn đoán

Chẩn đoán chính và chẩn đoán phụ dùng Condition với code bind tới CodeSystem ICD-10 VN, clinicalStatus = active, verificationStatus = confirmed. Khi cần phân biệt chẩn đoán nhập viện, chẩn đoán xuất viện, biến chứng và bệnh kèm, dùng Condition.category kết hợp ValueSet riêng của VN Core.

4.6 Điều trị

CarePlan mô tả kế hoạch điều trị tổng thể. MedicationRequest dùng cho đơn thuốc, theo TT 26/2025/TT-BYT về kê đơn ngoại trú và TT 27/2025/TT-BYT cho thuốc dược liệu, cổ truyền BHYT. Procedure ghi nhận thủ thuật và phẫu thuật, dùng mã ICD-9-CM bản 2026 theo QĐ 387/QĐ-BYT (05/02/2026) thay thế bản 2020 cũ.

4.7 Diễn biến

Với bệnh án nội trú, mỗi ngày điều trị có thể được mô tả như một sub-Encounter trong cây Encounter của ca nhập viện. Các đợt theo dõi sinh hiệu, đáp ứng điều trị và ghi chú điều dưỡng dùng Observation lặp theo thời gian. Trao đổi giữa bác sĩ điều trị và điều dưỡng có thể ghi qua Communication nếu hệ thống cần lưu vết.

4.8 Tổng kết và xuất viện

Phần tổng kết và xuất viện thường được đóng gói thành một Composition riêng với type bind tới mã LOINC 18842-5 (Discharge summary). Khi bệnh án xuất viện vẫn cần lưu bản PDF có chữ ký, hệ thống tạo thêm DocumentReference trỏ tới file PDF đã ký số, đồng thời liên kết với Composition gốc qua relatesTo.

5. Kết nối CCCD và VNeID đúng cách

TT 13/2025 yêu cầu bệnh án điện tử kết nối số định danh cá nhân hoặc tài khoản VNeID. Trong VN Core, hai khái niệm này được tách riêng theo đúng nguyên tắc thiết kế FHIR: CCCD là định danh hành chính trên Patient, còn VNeID là tài khoản xác thực ở lớp tích hợp.

VNCorePatient slice 5 loại định danh sau: CCCD, BHYT, BHXH, GKS (giấy khai sinh — slice cho trẻ chưa có CCCD) và HC (hộ chiếu — slice cho người nước ngoài). Slice tên là HC, không phải passport. NamingSystem cho VNeID đã được đánh dấu retired và không nằm trong Patient.identifier.

Profile: VNCorePatient
Parent: Patient
* identifier ^slicing.discriminator.type = #value
* identifier ^slicing.discriminator.path = "system"
* identifier contains
    CCCD 1..1 MS and
    BHYT 0..1 MS and
    BHXH 0..1 MS and
    GKS  0..1 MS and    // Giấy khai sinh — cho trẻ chưa có CCCD
    HC   0..1 MS and    // Hộ chiếu — cho người nước ngoài
    MRN  0..* MS

* identifier[CCCD].system = "http://fhir.hl7.org.vn/core/sid/cccd" (exactly)
* identifier[BHYT].system = "http://fhir.hl7.org.vn/core/sid/bhyt" (exactly)
* identifier[BHXH].system = "http://fhir.hl7.org.vn/core/sid/bhxh" (exactly)
* identifier[GKS].system  = "http://fhir.hl7.org.vn/core/sid/gks"  (exactly)
* identifier[HC].system   = "http://fhir.hl7.org.vn/core/sid/passport" (exactly)
// VNeID không có slice riêng. Tài khoản VNeID được model ở lớp xác thực,
// không phải Patient.identifier. VNVNeIDNS đã retired trong VN Core.

Với VNeID, mô hình tham chiếu hiện tại — chờ spec API chính thức từ Cục C06 và Bộ Y tế — là: ứng dụng VNeID cấp token định danh cho công dân; bệnh viện xác thực token đó qua API Cổng dịch vụ công, đối chiếu CCCD đính kèm token với Patient.identifier slice CCCD trong FHIR. Mọi sự kiện xác thực và truy cập bệnh án qua VNeID được ghi nhận bằng AuditEvent (xem mục 8) và, khi cần ghi nhận attestation cho phiên truy cập, bằng Provenance.

Khi cần ghi nhận quá trình kiểm tra định danh (ví dụ: nhân viên bàn tiếp đón quét CCCD chip, đối chiếu với VNeID), bệnh viện có thể profile VerificationResult để mô tả kết quả kiểm tra; đây là Resource hợp lệ trong R4 và phù hợp cho mục đích này. Tuyệt đối không dùng tên Resource không tồn tại như IdentityVerification.

Để hiểu sâu hơn về cách VN Core mô hình hóa định danh và VNeID, xem trang FHIR và VNeID.

6. Chữ ký số NĐ 137/2024 qua Provenance

NĐ 137/2024/NĐ-CP về giao dịch điện tử yêu cầu hồ sơ điện tử có chữ ký số hợp lệ để có giá trị pháp lý. Trong FHIR, chữ ký số được biểu diễn ở hai vị trí: Composition.attester ghi nhận người có thẩm quyền chứng thực bệnh án, còn Provenance.signature đóng gói chữ ký số thực tế dưới dạng PKCS#7/CMS hoặc JOSE/JWS detached signature.

Provenance trong FHIR là Resource ghi nhận chuỗi giám sát (chain of custody) và chứng thực: ai tạo Resource, dùng nguồn gì, ký vào lúc nào. Đây là khái niệm khác với AuditEvent — Provenance gắn với tính toàn vẹn và tin cậy của dữ liệu, AuditEvent gắn với lịch sử truy cập. Cả hai đều cần thiết cho bệnh án điện tử.

Ví dụ Provenance dưới đây dùng chữ ký PKCS#7 detached, phù hợp với nhiều giải pháp SmartCA và USB token tại Việt Nam. Trường targetFormat chỉ rõ định dạng của Resource đang được ký; sigFormat là application/pkcs7-signature; data chứa CMS bytes mã hoá base64.

{
  "resourceType": "Provenance",
  "target": [{ "reference": "Composition/comp-bm-001" }],
  "recorded": "2026-04-30T17:00:00+07:00",
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "author",
        "display": "Author"
      }]
    },
    "who": { "reference": "Practitioner/bs-tran-van-minh" }
  }],
  "signature": [{
    "type": [{
      "system": "urn:iso-astm:E1762-95:2013",
      "code": "1.2.840.10065.1.12.1.1",
      "display": "Author's Signature"
    }],
    "when": "2026-04-30T17:00:00+07:00",
    "who": { "reference": "Practitioner/bs-tran-van-minh" },
    "targetFormat": "application/fhir+json",
    "sigFormat": "application/pkcs7-signature",
    "data": "MIIHpwYJKoZIhvcNAQcCoIIHmDCCB5QCAQExDzANBglghkgBZQMEAgEFADCB..."
  }]
}

Khi bệnh viện chọn JOSE/JWS thay vì PKCS#7 (phổ biến với hệ thống cloud-native), chỉ cần đổi sigFormat sang application/jose và data chứa JWS detached signature mã hoá base64. Cấu trúc Provenance giữ nguyên.

Chứng thư số dùng để ký phải do tổ chức cung cấp dịch vụ tin cậy theo quy định của Bộ Thông tin và Truyền thông. Trong thực tế, hầu hết bệnh viện dùng SmartCA của VNPT, FPT-CA, hoặc USB token gắn vào máy bàn của bác sĩ. Một số mô hình mới đang thử nghiệm dùng CCCD chip kết hợp PIN cá nhân để ký số, phù hợp định hướng tích hợp với VNeID.

7. Bảo mật theo Luật 91/2025 và NĐ 356/2025

Luật 91/2025/QH15 về Bảo vệ dữ liệu cá nhân (hiệu lực 01/01/2026) và NĐ 356/2025/NĐ-CP hướng dẫn thi hành phân loại dữ liệu y tế là dữ liệu cá nhân nhạy cảm, đòi hỏi mức bảo vệ cao nhất. Vi phạm có thể bị phạt tới 5% doanh thu năm trước. Bệnh án điện tử FHIR phải được thiết kế từ đầu để đáp ứng các yêu cầu này.

NĐ 356/2025 còn yêu cầu bệnh viện chỉ định nhân sự bảo vệ dữ liệu cá nhân (DPO) và lập danh mục dữ liệu cá nhân nhạy cảm. Trong dự án FHIR, danh mục này thường liệt kê tất cả Resource lâm sàng (Condition, Observation, MedicationRequest, AllergyIntolerance...) và Patient.identifier (CCCD, BHYT, BHXH).

8. Audit log truy cập (AuditEvent)

Luật 91/2025 buộc mọi sự kiện truy cập dữ liệu cá nhân nhạy cảm phải được ghi log. Trong FHIR, mỗi lần đọc, sửa hoặc xoá Resource bệnh án sinh ra một AuditEvent. Đây là Resource khác hoàn toàn với Provenance: AuditEvent ghi nhận sự kiện hệ thống và bảo mật, còn Provenance ghi nhận chuỗi giám sát và chữ ký.

{
  "resourceType": "AuditEvent",
  "type": {
    "system": "http://terminology.hl7.org/CodeSystem/audit-event-type",
    "code": "rest",
    "display": "RESTful Operation"
  },
  "subtype": [{
    "system": "http://hl7.org/fhir/restful-interaction",
    "code": "read"
  }],
  "action": "R",
  "recorded": "2026-04-30T17:30:00+07:00",
  "outcome": "0",
  "agent": [{
    "who": { "reference": "Practitioner/bs-tran-van-minh" },
    "requestor": true,
    "network": { "address": "10.20.30.40", "type": "2" }
  }],
  "source": {
    "site": "BV Bach Mai",
    "observer": { "reference": "Device/emr-frontend-bm" }
  },
  "entity": [{
    "what": { "reference": "Composition/comp-bm-001" },
    "type": { "system": "http://terminology.hl7.org/CodeSystem/audit-entity-type", "code": "2" }
  }]
}

9. Lộ trình triển khai bệnh án điện tử FHIR 12–18 tháng

Lộ trình dưới đây là tham chiếu cho bệnh viện đa khoa tuyến tỉnh hoặc tuyến trung ương đã có EMR cơ bản và muốn bổ sung lớp FHIR để đáp ứng TT 13/2025 cùng yêu cầu liên thông VNeID, BHXH. Bệnh viện nhỏ hơn có thể rút gọn các bước 4–5.

Chi phí điển hình cho lộ trình 12–18 tháng vào khoảng 500 triệu đến 2 tỷ đồng tuỳ quy mô bệnh viện, gồm: hạ tầng FHIR server, công sức đội phát triển nội bộ hoặc đối tác, và phí tích hợp với VNeID, BHXH. Khoản đầu tư này nên được đặt cùng với chi phí an toàn thông tin và DPO cho phù hợp Luật 91/2025.

10. Câu hỏi thường gặp về bệnh án điện tử FHIR

Bệnh viện chúng tôi đã có EMR rồi, cần làm gì thêm với FHIR?

Bắt đầu bằng audit gap với TT 13/2025: kiểm tra xem EMR đã kết nối CCCD chưa, đã có chữ ký số đúng theo NĐ 137/2024 chưa, đã có log truy cập đầy đủ chưa. Sau đó dựng lớp FHIR API phía trên cơ sở dữ liệu EMR hiện có. Không cần viết lại EMR từ đầu.

Có phải chuyển toàn bộ bệnh án lịch sử sang FHIR không?

Không bắt buộc. Cách thực dụng nhất là tập trung dữ liệu mới và bệnh án đang điều trị, rồi chuyển dần dữ liệu lịch sử khi có nhu cầu (ví dụ: bệnh nhân tái khám, yêu cầu của BHXH). Bệnh án giấy đã đóng có thể số hoá thành DocumentReference với file PDF có chữ ký số bổ sung.

VNeID kết nối thế nào về mặt kỹ thuật?

Mô hình tham chiếu là: ứng dụng VNeID cấp token định danh; hệ thống bệnh viện xác thực token qua API Cổng dịch vụ công; CCCD trong token được đối chiếu với Patient.identifier slice CCCD. VNeID không trở thành identifier riêng trên Patient. Spec API chính thức của Bộ Y tế và Cục C06 đang trong quá trình hoàn thiện — bệnh viện nên thiết kế kiến trúc cho phép thay thế đầu nối khi spec phát hành.

Có khác biệt gì giữa Provenance và AuditEvent?

Provenance ghi chuỗi giám sát và chữ ký: ai tạo Resource này, dùng nguồn gì, ký vào lúc nào. AuditEvent ghi sự kiện truy cập: ai đã đọc Resource này, lúc nào, từ đâu. Bệnh án điện tử cần cả hai. Provenance trả lời câu hỏi "Resource này có đáng tin không?", AuditEvent trả lời "Ai đã xem Resource này?".

FHIR có thay XML 4210 không?

Hiện tại chưa. BHXH vẫn nhận dữ liệu KCB BHYT theo định dạng XML 4210 (theo QĐ 4210/QĐ-BYT, sửa đổi qua chuỗi QĐ 130, QĐ 4750, QĐ 3176). Bệnh viện cần adapter chuyển từ FHIR sang XML 4210 để gửi BHXH. Xu hướng dài hạn là FHIR-native, nhưng chưa có văn bản chính thức thay thế 4210.

11. Tham chiếu pháp lý và đọc tiếp

Bản đồ trích dẫn

Đọc tiếp trong knowledge hub

Thuật ngữ

• EMR / EHR: Bệnh án điện tử / Hồ sơ sức khoẻ điện tử.
• Composition: Hợp phần — Resource đóng vai trò header bệnh án trong FHIR.
• Provenance: Nguồn gốc — Resource ghi nhận chuỗi giám sát và chữ ký số (ai tạo, ai sửa, dùng nguồn nào). Khác với AuditEvent.
• AuditEvent: Resource ghi nhận sự kiện truy cập (đọc, ghi, xoá). Bắt buộc theo Luật 91/2025.
• VerificationResult: Resource FHIR R4 hợp lệ để mô hình kết quả xác minh định danh hoặc chứng chỉ. Không nhầm với IdentityVerification — không tồn tại trong R4.
• VNeID: Ứng dụng định danh điện tử quốc gia. Trong VN Core, VNeID nằm ở lớp xác thực, không phải Patient.identifier.
• IPS: International Patient Summary — chuẩn FHIR cho tóm tắt sức khoẻ bệnh nhân xuyên biên giới.