Bài 23 – Dịch vụ công đất đai và chia sẻ dữ liệu liên cơ quan cần kiến trúc nào? tiếp tục series Hệ thống thông tin BĐS V2. Bài tập trung vào cách tổ chức dữ liệu, nguồn, thời gian, quyền và kiến trúc tích hợp để thông tin có thể được sử dụng đáng tin trong quản lý và thị trường.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 30/09/2026: Bài viết phục vụ học tập và giảng dạy trong series Hệ thống thông tin BĐS V2. Nội dung pháp lý được đối chiếu theo văn bản hiện hành được nêu tại phần nguồn; khi áp dụng thực tế cần kiểm tra bản sửa đổi, văn bản hướng dẫn và phạm vi dữ liệu cụ thể. Các tình huống/số liệu minh họa được ghi rõ là giả lập.
Ranh giới với các series khác: Bài này trình bày kiến trúc và dữ liệu của HTTT đất đai. Phân tích điều kiện pháp lý cụ thể thuộc Pháp lý BĐS; thao tác GIS/API/CSDL chi tiết thuộc Tin học BĐS.
1. Số hóa dịch vụ công không phải scan biểu mẫu
Nếu người dân điền lại dữ liệu đã có, tải lại giấy tờ cơ quan đã quản lý và cán bộ nhập lại vào LIS thì chỉ thay giấy bằng màn hình. Chuyển đổi số thật cần tái thiết kế luồng dữ liệu.
2. Kiến trúc tách kênh – dịch vụ – workflow – record
Cổng DVC là kênh; API/service layer cung cấp dịch vụ; workflow quản lý case; LIS core giữ legal record. Tách lớp giúp thay giao diện mà không làm ảnh hưởng CSDL lõi và giảm quyền truy cập trực tiếp.
3. Nguyên tắc once-only
Khi pháp luật và quyền truy cập cho phép, cơ quan không nên yêu cầu lại dữ liệu đã có/sẵn sàng chia sẻ. Điều này đòi hỏi định danh công dân/doanh nghiệp, data contract và cơ chế xác minh dữ liệu thay vì upload bản sao.
| Lớp | Vai trò | Ví dụ |
|---|---|---|
| Channel | Tương tác | Cổng DVC/app |
| Service/API | Dịch vụ dùng chung | Tra cứu thửa/chủ thể |
| Workflow | Case/SLA | Đăng ký biến động |
| Core record | Trạng thái pháp lý | Parcel/RRR |
| Integration | Liên cơ quan | Thuế/dân cư/thanh toán |
4. Liên thông dân cư, doanh nghiệp và thuế
LIS có thể cần xác thực danh tính/chủ thể, trạng thái doanh nghiệp, nghĩa vụ tài chính. Không nên sao chép toàn bộ CSDL nguồn; chỉ lấy/đối chiếu dữ liệu cần thiết theo mục đích và quyền.
5. API và event
API phù hợp truy vấn/yêu cầu đồng bộ; event/webhook phù hợp thông báo trạng thái thay đổi. Ví dụ TAX_OBLIGATION_COMPLETED có thể kích hoạt workflow tiếp tục mà không cần cán bộ kiểm tra thủ công.
6. Correlation ID và idempotency
Một hồ sơ đi qua nhiều hệ thống cần mã theo dõi chung/correlation ID. Interface phải chịu được gửi lại message mà không tạo hồ sơ hoặc thanh toán trùng; đây là idempotency.
7. Phân quyền và audit
Người dân chỉ xem hồ sơ của mình; cán bộ xem theo nhiệm vụ; hệ tích hợp dùng service account. Mọi truy cập/sửa cần log. Chia sẻ dữ liệu phải có purpose, scope và retention.
8. Đồng bộ trạng thái cho người dân
Trạng thái hiển thị nên map từ workflow thật, có timestamp và giải thích. Tránh tình trạng back-office đã xử lý nhưng cổng vẫn hiển thị cũ hoặc dùng một trạng thái chung 'đang xử lý' trong nhiều tuần.
Khung kiến trúc: dữ liệu phải đi qua những lớp nào?
Ở hệ thống quản lý đất đai, một chỉ tiêu hoặc bản ghi đáng tin không xuất hiện trực tiếp từ giao diện. Nó đi qua chuỗi nguồn → tiếp nhận → chuẩn hóa → định danh → kiểm soát chất lượng → lưu trữ có lịch sử → semantic/service → người dùng. Nếu bỏ một lớp, rủi ro thường bị đẩy sang người dùng cuối.
| Lớp | Câu hỏi kiểm soát | Đầu ra |
|---|---|---|
| Source | Nguồn nào, quyền dùng gì? | Provenance |
| Ingestion | Batch/API/event? | Raw record |
| Standardization | Đơn vị/code/format? | Normalized data |
| Identity | Đối tượng nào? | Master/crosswalk |
| Quality | Có hợp lệ/trùng/hết hạn? | DQ flags |
| History | Phiên bản nào? | Temporal record |
| Semantic/service | Định nghĩa nghiệp vụ? | API/KPI/view |
| Consumption | Ai dùng để làm gì? | Decision/service |
Đặc biệt, lineage phải xuyên chuỗi: từ một KPI/thuộc tính hiển thị có thể truy về bản ghi nguồn và rule biến đổi. Điều này giúp giải thích sai lệch và tái tạo kết quả khi có kiểm tra.
Ma trận đánh giá nguồn và độ tin cậy
Không nên gắn nhãn nguồn “tốt/xấu” một cách tuyệt đối. Nguồn phù hợp phụ thuộc trường dữ liệu và mục đích. Một nguồn có authority cao nhưng cập nhật chậm; nguồn nền tảng nhanh nhưng thiên lệch. Hãy đánh giá theo field/use case.
| Tiêu chí | Câu hỏi | Ví dụ kiểm soát |
|---|---|---|
| Authority | Ai tạo/chịu trách nhiệm? | Cơ quan/hệ nguồn |
| Coverage | Bao phủ gì? | Địa bàn/phân khúc |
| Freshness | Mới đến đâu? | refresh_at/SLA |
| Granularity | Chi tiết mức nào? | parcel/unit/project |
| Bias | Thiên lệch gì? | listing bias/sample bias |
| Traceability | Có bằng chứng? | source_id/document |
| Permission | Được dùng/chia sẻ? | license/purpose |
Source score chỉ hỗ trợ quyết định; không được dùng một điểm tổng để che mất lỗi nghiêm trọng. Ví dụ dữ liệu không có quyền sử dụng thì freshness cao cũng không làm nó trở thành nguồn hợp lệ.
Tình huống giả lập phục vụ giảng dạy
Người dân nộp hồ sơ trực tuyến, hệ DVC có CCCD và mã thửa; LIS vẫn yêu cầu cán bộ nhập lại, thuế trả PDF qua Email. Hãy thiết kế luồng liên thông giảm nhập lại.
Không được trả lời chỉ bằng 'lấy nguồn chính xác nhất'. Hãy xác định: đối tượng nào, loại dữ liệu gì, source authority theo field, thời gian hiệu lực, độ trễ, quyền dùng, rule hợp nhất và cách hiển thị uncertainty. Đây là cách phân biệt tư duy HTTT với việc gom dữ liệu vào Excel.
| Bước | Câu hỏi | Kết quả phải có |
|---|---|---|
| 1 | Đang hỏi dữ liệu/khái niệm nào? | Semantic definition |
| 2 | Nguồn nào tạo/khẳng định? | Source matrix |
| 3 | Thời điểm nào? | Valid/record time |
| 4 | Có mâu thuẫn/trùng? | Reconciliation rule |
| 5 | Ai quyết định exception? | Owner/steward |
| 6 | Người dùng thấy gì? | Value + source + confidence |
Khung áp dụng thực tế
- Vẽ sequence hồ sơ biến động qua DVC–workflow–LIS–thuế.
- Xác định 5 API và 5 event.
- Thiết kế correlation ID/idempotency.
- Lập access/audit matrix.
Những sai lầm cần tránh
- Cho cổng DVC kết nối trực tiếp DB core.
- Nhập lại dữ liệu từ hệ khác.
- Không có correlation ID.
- Đồng nhất workflow status với legal state.
Phòng thí nghiệm dữ liệu: kiểm tra trước khi đưa lên dashboard hoặc dịch vụ
Hãy chọn một trường/chỉ số quan trọng và đi ngược lineage: người dùng nhìn thấy gì → định nghĩa ở semantic layer → rule biến đổi → curated record → raw source. Tại mỗi bước, ghi owner, timestamp và lỗi có thể xảy ra. Nếu không truy ngược được, chưa nên coi dữ liệu là 'nguồn sự thật'.
| Kiểm thử | Đạt khi | Không đạt khi |
|---|---|---|
| Identity | Một đối tượng map ổn định | Join bằng tên tự do |
| Semantics | Có data dictionary | Mỗi phòng hiểu khác |
| Time | Có effective/refresh | Không biết dữ liệu cũ |
| Provenance | Có source/evidence | Không truy nguồn |
| Quality | Có rule/exception | Lỗi chỉ phát hiện thủ công |
| Permission | Có purpose/access | Sao chép tự do |
Bài tập phản biện
Chọn một quyết định thực tế mà dữ liệu bài này hỗ trợ. Viết ba trường hợp hệ thống có thể đưa ra kết luận sai dù không có lỗi phần mềm: sai định nghĩa, sai thời điểm, sai nguồn hoặc sai phạm vi. Với mỗi trường hợp, đề xuất một guardrail ở tầng dữ liệu/quy trình thay vì chỉ cảnh báo người dùng.
Câu hỏi tự kiểm tra
- Khái niệm này có đang bị giản lược thành một field/cờ nhị phân quá mức không?
- Nguồn nào có thẩm quyền hoặc phù hợp nhất cho từng trường dữ liệu?
- Thông tin có hiệu lực ở thời điểm nào và có phiên bản không?
- Nếu hai nguồn mâu thuẫn, ai và theo rule nào xử lý?
- Người dùng có truy được source và methodology không?
- Dữ liệu này thuộc master, transaction, reference hay analytical layer?
Thiết kế hợp đồng dữ liệu giữa các cơ quan
API specification chỉ nói cấu trúc kỹ thuật; data contract còn phải nói semantic, owner, refresh, SLA, error code, version, retention và mục đích sử dụng. Ví dụ trường 'status' từ cơ quan thuế cần code list rõ: CREATED, NOTIFIED, PARTIALLY_PAID, COMPLETED, CANCELLED… thay vì text tự do. Khi version API thay đổi, consumer phải có thời gian chuyển đổi và monitoring tỷ lệ lỗi.
Liên thông bền vững cần tránh tích hợp điểm–điểm giữa hàng chục hệ thống. Integration platform/API gateway và event bus giúp quản lý version, auth, throttling và observability tập trung.
Ghi nhớ trong 30 giây
- Dịch vụ công số tốt không phải số hóa biểu mẫu giấy mà là tái thiết kế luồng dữ liệu.
- Nguyên tắc once-only giúp giảm yêu cầu người dân nộp lại dữ liệu cơ quan nhà nước đã có và được phép chia sẻ.
- Liên thông cần định danh, hợp đồng dữ liệu, API/sự kiện, bảo mật và audit.
- Workflow TTHC và legal record của LIS phải liên kết nhưng không đồng nhất.
- Trạng thái hồ sơ phải được đồng bộ theo sự kiện, tránh nhập thủ công ở nhiều hệ thống.
Nguồn tham khảo
- Luật Đất đai 2024 – Hệ thống thông tin quốc gia về đất đai và kết nối liên thông.
- Nghị định 101/2024/NĐ-CP – đăng ký đất đai, cấp Giấy chứng nhận và HTTT đất đai.
- Thông tư 09/2024/TT-BTNMT – yêu cầu phần mềm ứng dụng của HTTT quốc gia về đất đai.
- Tài liệu quy định chia sẻ dữ liệu và chỉ đạo chuyển đổi số của TP.HCM do người dùng cung cấp.
Bài tiếp theo: “Case study: kiến trúc HTTT đất đai từ cơ sở dữ liệu địa chính đến dịch vụ cho người dân”.