International FHIR landscape: US Core, JP Core, KR Core, CH Core, AU Core, VN Core

Multiple jurisdictions publish FHIR Implementation Guides for local requirements. This article compares five IGs with traceable publication and version-history pages—US Core, JP Core, KR Core, CH Core, and AU Core. External versions are a dated snapshot and must be rechecked before implementation decisions.

Audience: regulators benchmarking international models, hospital CIOs choosing a deployment pattern, engineers looking to borrow profiles from another country's IG, and researchers tracking global health interoperability trends.

TL;DR

  • All five reference IGs in the comparison had an R4 line at the 18 July 2026 review; this is not a claim about every IG worldwide.
  • Common structure includes Profiles, Extensions, terminology, examples, guidance, and—depending on scope—actors/CapabilityStatements.
  • Publication status, publisher authority, and legal force must be separated; they are not synonyms.
  • VN Core is a pre-1.0 trial-use line that uses other IGs for design comparison, not as proof of equivalent maturity.
  • VN Core should advance only after implementation evidence, testing, and a published governance mechanism; the project does not promise a 1.0.0 date or HL7 Affiliate status.

On this page

  1. Selected public initiatives used for comparison
  2. Comparing 5 reference IGs across 12 dimensions
  3. US Core 9.0.0 — STU9 on FHIR R4
  4. JP Core — governance and package variants
  5. KR Core 2.0.0 — STU2 published by HL7 Korea
  6. CH Core 6.0.0 — minimal IG bound to EPD
  7. AU Core 2.0.0 — two conformance modes
  8. Brazil RNDS — openEHR + FHIR hybrid
  9. VN Core — current state and maturity conditions
  10. Five lessons for Vietnam
  11. Frequently asked questions
  12. References and further reading

1. Selected public initiatives used for comparison

A jurisdictional Core FHIR IG describes how FHIR applies in a local context: Profiles, Extensions, terminology, examples, and—where present—actor/API requirements. The table includes only the five IGs checked directly against publication pages; the last column describes document status, not market adoption.

Country IG name Version Verified publication note
United StatesUS Core9.0.0 STU9Current published release, FHIR R4
JapanJP Core1.1.2-clinsLatest clinical-sharing branch; not approved by HL7 Japan
South KoreaKR Core2.0.0 STU2Current published release, FHIR R4
SwitzerlandCH Core6.0.0 STU6Current stable release; 7.0.0 is in ballot
AustraliaAU Core2.0.0Current Working Standard, FHIR R4
VietnamVN Core0.8.0 trial-useOmi HealthTech initiative; not an official national standard

Source: each IG's publication and version-history pages (see References), reviewed 18 July 2026. A public website alone does not establish adoption or legal force.

2. Comparing 5 FHIR IGs on verifiable dimensions

The five IGs below represent different governance models. Versions were reviewed on 18 July 2026; artifact counts are indicative and must be rechecked against the applicable package before a formal decision.

Dimension US Core JP Core KR Core CH Core AU Core
Version9.0.0 STU91.1.2-clins (latest branch)2.0.0 STU26.0.0 STU62.0.0 Working Standard
FHIR baseR4R4R4R4R4
Document statusSTU9Active build; self-declared as not approved by HL7 JapanSTU2STU6; separate STU7 ballotWorking Standard R2
Actor/API surfaceActors + REST interactionsExample CapabilityStatementActors + CapabilityStatementsSpecific APIs deferred to related IGsProfile-only or Profile + Interaction
Publisher/developerHL7 InternationalJAMI FHIR Working GroupHL7 KoreaHL7 SwitzerlandHL7 Australia

Do not compare maturity by raw artifact counts. Reuse decisions must inspect the exact package, dependencies (for example AU Base), and CapabilityStatement.

3. US Core 9.0.0 — STU9 on FHIR R4

US Core 9.0.0 was the current HL7 International publication at review time, labelled STU9 and based on FHIR R4. It defines profiles and minimum REST interactions for patient-data access in the US context; a specific legal obligation must be read from the applicable ONC rule rather than inferred from the IG alone.

US Core publishes actors, CapabilityStatements, and testable conformance expectations alongside the US certification ecosystem. The useful VN Core lesson is to state roles, interactions, search, and assertions clearly—not to transpose US certification rules into Vietnam.

This page does not use an adoption estimate without a cited dataset. When referencing US Core, pin the package and distinguish IG requirements, certification requirements, and the actual capability of each endpoint.

4. JP Core — governance and package variants

JP Core is a foundational FHIR IG for Japan developed by a JAMI working group. The reviewed latest branch was 1.1.2-clins, a clinical-record-sharing variant; its own guidance says it is not approved by HL7 Japan. Implementers must therefore pin the exact package/variant instead of referring to one generic “official” release.

JP Core identifies the JAMI working group as its developer. The direct lesson is to identify publisher, approval status, package, and use-case variant clearly; rollout speed or cultural traits should not be asserted without supporting research.

VN Core can study JP Core's guidance, profiles, and terminology while preserving the distinction between “developed by a working group” and “approved by an HL7 Affiliate or regulator.”

5. KR Core 2.0.0 STU2 — published by HL7 Korea

KR Core 2.0.0 is an R4-based STU2 publication from HL7 Korea at hl7korea.or.kr. Profile, terminology, and actor scope must be read from the artifacts and CapabilityStatements of that exact release; this page does not infer adoption across South Korea's EMR ecosystem without a verified public tracker.

Any Coverage/Claim pattern should be reused only after direct comparison with KR Core artifacts and bindings. Similar insurance systems do not make two data contracts equivalent; Vietnam's healthcare-output XML still requires its own mapping and tests.

KR Core 2.0.0 is an R4-based STU2 publication with actor CapabilityStatements. VN Core can study its actor/conformance separation and Coverage modeling without inferring hospital adoption in the absence of a verified public tracker.

6. CH Core 6.0.0 — foundation scope for Switzerland

CH Core 6.0.0 is the stable STU6 line managed by HL7 Switzerland; 7.0.0 was in ballot at review time. It provides foundational profiles for Switzerland and describes its relationship with the Electronic Patient Record, while specific EPR APIs live in related IGs.

The publication at fhir.ch/ig/ch-core provides an artifacts page and describes CH Core's foundation scope. API scope for the Swiss Electronic Patient Record is defined in related IGs; design philosophy or implementation effort should not be inferred from profile count alone.

The relevant lesson is to keep scope verifiable and prioritize use cases with clear evidence. VN Core 0.8.0 has 86 Profiles across EMR, structured health check-up, IPS, and financial workflows; artifact volume does not replace implementation evidence or maturity.

7. AU Core 2.0.0 — two conformance modes

AU Core 2.0.0 is a Working Standard published by HL7 Australia with participation from the Australian Digital Health Agency (ADHA), defining core requirements for the Australian context. Its general-requirements page defines two noteworthy conformance modes.

Profile Only Support requires a system to comply with data structure (must-support, slicing, terminology binding) when emitting or receiving FHIR resources. Profile Support + Interaction Support adds the RESTful interactions (search, read, create, update) per the prescribed CapabilityStatement. A given hospital can declare Profile Only initially, then upgrade to Profile + Interaction later.

This structure is fundamentally different from the often-misunderstood "tier 1/tier 2" model: AU Core does not stratify by profile complexity, it cleanly separates data conformance from interaction conformance. Lesson for VN Core: a clear conformance mode lets hospitals choose a deployment path that matches their capability, instead of forcing everyone to ship a full RESTful API on day one.

8. Brazil RNDS — FHIR-based national exchange

Public documentation for Brazil's Rede Nacional de Dados em Saúde (RNDS) confirms that FHIR is used for national health-data exchange. The sources cited below do not establish that RNDS mandates one uniform openEHR storage architecture underneath.

Brazil's Ministry of Health (Ministério da Saúde) operates RNDS. Any comparison must distinguish the national FHIR exchange specification from internal storage choices made by a platform or vendor; the two architectural layers are not interchangeable claims.

RNDS is a useful reference when evaluating national exchange architecture. Choosing FHIR, openEHR, or a hybrid storage model for Vietnam must follow defined use cases, governance, operating cost, and test evidence; this page does not prescribe one as the default.

9. VN Core — current state and maturity conditions

VN Core is at version 0.8.0 draft, initiated by Omi HealthTech as a trial-use open contribution. Canonical URL http://fhir.hl7.org.vn/core/, base FHIR R4 (4.0.1), with 86 Profiles, 56 Extensions, 165 CodeSystems, 168 ValueSets, 27 Logical Models, and 249 example files authored using FSH and the SUSHI compiler.

Dimension VN Core 0.8.0 (today) Next maturity target (no committed date)
Version0.8.0 trial-useSet through governance after implementation evidence
Profiles86 (Patient, Encounter, Coverage, Claim, Medication, KSK SDC, IPS, TVM...)Stable pilot-validated subset
Extensions56 (53 local + 3 official patient-* reused)Governance and backward-compatibility review
Local CodeSystems165 (Vietnamese ICD-10, ICD-9-CM, 54 ethnicities, 34-province administrative division, BHYT subjects, SNOMED CT VN, TVM, lab indicators, healthcare facility codes...)Versioned source-of-truth governance
ValueSets168Expansion and versioning policy
Examples249 example files (227 FHIR instances)Pilot fixtures + conformance test suite
Adoption pathTrial-use open contributionPilot-validated recommendation first; any mandate depends on official governance
GovernanceInitiated by Omi HealthTechHybrid Working Group path with Ministry of Health participation
Test suiteSUSHI build + IG Publisher QAVietnam Connectathon + Inferno-style suite

There is no common metric that places VN Core a fixed number of months behind another project. A useful comparison is capability by capability: actors/CapabilityStatements, profiles/terminology, test suites, pilot evidence, change control, and governance authority.

Concrete reference points: reviewed patterns include identifier slicing, Coverage/Claim, actors/CapabilityStatements, and separation of data conformance from interaction conformance. Reuse decisions must trace to specific artifacts; this page does not claim direct lineage where no traceability record exists.

10. Five lessons for Vietnam

  1. Reasonable scope, prioritize evidenced use cases. VN Core 0.8.0 has 86 Profiles across Patient/Encounter, finance, medication, health check-up, IPS, traditional medicine, and device clusters. Each cluster still needs pilots and conformance tests; a legal deadline does not make a profile mandatory by itself.
  2. A test suite is part of conformance evidence. Inferno and Connectathons are useful reference models because they expose test criteria and issue logs. VN Core needs a workable test suite before proposing any mandate.
  3. Terminology governance needs dedicated capacity. Localizing ICD-10, a SNOMED CT subset, the 34-province administrative catalog, BHYT terminology, and the 54-ethnic-group catalog requires source, version, and licensing governance; it is not a secondary profile-authoring task.
  4. Do not turn technical guidance into a mandate without authority and evidence. VN Core should distinguish trial-use recommendations, pilot evidence, and regulatory decisions. Lessons should come from published ballot, actor/conformance, and implementation-feedback processes—not unsourced judgments about a country.
  5. Governance should represent affected parties. A sustainable mechanism should include regulators, healthcare organizations, vendors, experts, and data users, with published decision rights, change control, and test evidence. Omi HealthTech initiated this trial-use line; no future transfer or Working Group model is being decided on behalf of those parties here.

11. Frequently asked questions

Can Vietnam adopt JP Core directly?

No. The identifier systems are completely different (Vietnam's 12-digit national ID card (CCCD) follows different issuance rules than Japan's 12-digit MyNumber); Vietnam's ICD-10 has local extensions per Decision 4469/QĐ-BYT (Ministry of Health); and the 34-province administrative catalog created by Resolution 202/2025/QH15 does not exist in JP Core. That said, the profile design patterns — how identifiers are sliced, how ethnicity is modeled as an extension — are directly transferable.

Does US Core cover Vietnam's needs out of the box?

No. US Core has no notion of multi-tier social health insurance (BHYT), no 54-ethnic-group catalog, no commune/ward level in Address, and no concept of care tier. Vietnam must build its own CodeSystems and Extensions for these domains. US Core works as a pattern reference, not as a directly applicable standard.

Has an HL7 Affiliate Vietnam model or budget been decided?

No. The site does not claim that an Affiliate has been recognized, set a transfer model, or publish a budget. Any future proposal must separate organizational, working-group, and technical-infrastructure costs and be decided by the authorized parties.

When can VN Core advance in maturity?

No date or next version has been approved. Minimum conditions include evidenced pilots, a workable test/validator suite, public review, a compatibility policy, and an authorized governance mechanism. The 86 Profiles and 249 example files describe scope; they do not establish maturity by themselves.

12. References and further reading

Core IGs and publication sources reviewed

Surrounding ecosystem

Continue reading on hl7.org.vn

→ Profiling and Implementation Guides in FHIR → Vietnam FHIR timeline and governance milestones to verify → For regulators: governance of a national IG → FHIR and HL7 glossary