NP Core Implementation Guide - Local Development build (v1.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Conformance

This page describes the conformance expectations that apply to all systems claiming conformance to the NP Core Implementation Guide.

Conformance Verbs

This guide uses the RFC 2119 vocabulary for conformance requirements:

Must Support

Elements marked Must Support (MS) in a profile carry the following obligations:

• Producing systems SHALL populate a Must Support element if data for that element is available.
• Consuming systems SHALL be capable of receiving and meaningfully processing a Must Support element without error or data loss.
• A Must Support element for which no data is available MAY be omitted, unless the profile gives the element a minimum cardinality of 1, in which case a Data Absent Reason extension SHALL be used (see Unsupported Data).

Must Support does not imply that an element is required (mandatory cardinality) unless the profile also specifies a minimum cardinality of 1.

Claiming Conformance

A FHIR resource instance claims conformance to an NP Core profile by including the profile canonical URL in meta.profile. For example, a Patient conformant to NP Core shall include:

meta.profile = "http://fhir.digitalhealth.gov.np/core/StructureDefinition/np-core-patient"

Systems producing or consuming NP Core-profiled resources are expected to validate their data against the published StructureDefinitions.

Conformance for Systems

Where meta.profile is how an instance claims conformance, a CapabilityStatement is how a system does. A system conforms to NP Core as one or more of the three actors, each defined by its own CapabilityStatement:

A system claims an actor by asserting instantiates of that actor's CapabilityStatement in its own CapabilityStatement, and SHALL declare exactly which NP Core profiles it supports in rest.resource.supportedProfile.

• An NP Core Server SHALL support all NP Core profiles, together with the interactions and search parameters its CapabilityStatement declares.
• An NP Core Creator and an NP Core Consumer SHOULD support all NP Core profiles unless the system plays a limited or specialised role, and SHALL fully conform to every profile it declares.

Conformance is checked in two places. The profiles a system declares are verified instance by instance, by validating exchanged resources against the published StructureDefinitions as required under Claiming Conformance. The actor CapabilityStatements define the interactions and search parameters a conformance checker exercises against the system.

Identifier Requirements

Patient Identifiers

Every NPCorePatient instance SHALL carry:

• identifier[healthId] - Nepal Health ID issued by MoHFS.
• identifier[nationalId] - Nepal National ID issued by DONIDCR is supported and recommended, but is not mandatory in the current profile (0..1).

Practitioner Identifiers

Every NPCorePractitioner instance SHALL carry at least one council registration identifier (invariant np-prac-1):

• Nepal Medical Council (NMC)
• Nepal Nursing Council (NNC)
• Nepal Ayurveda Medical Council (NAMC)
• Nepal Health Professional Council (NHPC)
• Nepal Pharmacy Council (NPC)

Health Facility Identifiers

NPCoreHealthFacility instances representing registered health facilities SHALL carry identifier[nhfrCode] using the NHFR NamingSystem (http://nhfr.digitalhealth.gov.np). Systems representing a health facility registered in the National Health Facility Registry SHALL use NPCoreHealthFacility rather than the base NPCoreOrganization.

Terminology Binding Strengths

This guide uses the standard FHIR binding strengths:

Unsupported Data

When a system does not have data for an element that is marked Must Support, it SHALL either omit the element entirely or, where clinically required, use a Data Absent Reason extension.

Calendar and Dates

Nepal's official civil calendar is Bikram Sambat (BS), which runs roughly 56 years and 8 months ahead of the Gregorian (AD) calendar. FHIR makes no provision for non-Gregorian calendars.

• All FHIR date, dateTime and instant values in NP Core resources SHALL be expressed in the Gregorian (AD) calendar, as required by the FHIR specification.
• Systems that capture dates in Bikram Sambat SHALL convert them to Gregorian before exchange, and SHALL NOT place BS year values in Gregorian date elements.

This rule matters because the failure is silent. A Bikram Sambat date written straight into a Gregorian element - 2047-02-01 in Patient.birthDate in place of 1990-05-15 - is a well-formed date that passes every validator while being wrong by about 57 years. Nothing downstream can tell it apart from a legitimate value, so age-derived logic such as paediatric dosing, immunisation windows, growth monitoring and age-banded reporting fails without any error being raised.

Preserving the Original Bikram Sambat Value

Where a date was genuinely captured in Bikram Sambat and that capture is worth keeping for display or audit, the Bikram Sambat Date extension records the original BS string alongside the Gregorian value. It may be used on any date or dateTime element, so it attaches to Patient.birthDate directly, and on a period it attaches to Encounter.period.start and Encounter.period.end individually rather than to the period as a whole. It is deliberately not available on instant, which records a machine timestamp rather than a calendar date a person entered. The Gregorian element remains the value of record and the extension never substitutes for it. FHIR cannot check that the two calendars agree, so keeping them consistent is the capturing system's responsibility, and the extension SHOULD be populated only where a faithful BS capture exists rather than derived after the fact.

"birthDate": "1990-08-16",
"_birthDate": {
  "extension": [
    {
      "url": "http://fhir.digitalhealth.gov.np/core/StructureDefinition/np-core-bikram-sambat-date",
      "valueString": "2047-04-32"
    }
  ]
}

Bikram Sambat months vary between 29 and 32 days, so 2047-04-32 (32 Shrawan 2047) is a valid BS date even though no Gregorian month has a 32nd day. The extension accepts the same partial precisions FHIR allows on a date - YYYY, YYYY-MM or YYYY-MM-DD.

Two further rules apply to how the BS value is recorded:

• The precision of the BS value SHOULD match the precision of the Gregorian element it accompanies. A year-only birth year is a common and legitimate capture for elderly patients, and pairing a year-only Gregorian birthDate with a full BS date would assert a precision the source never had.
• There is deliberately no separate Bikram Sambat dateTime form. Bikram Sambat is a calendar with no time component, so on elements that carry a dateTime - such as Encounter.period.start and Encounter.period.end - the extension records only the BS calendar date and the time of day lives solely in the Gregorian value. Where the Gregorian value carries a time, the BS date SHALL correspond to the Asia/Kathmandu local date of that instant, not its UTC date; the two fall on different days for instants either side of local midnight.

Interoperability Expectations

• Coded elements SHALL use the system URIs specified in the corresponding Identifier or CodeSystem resources defined in this guide.
• Narrative (text) is optional but SHOULD be provided where it improves human readability.
• Resources exchanged between systems SHALL be valid against the base FHIR R4 specification in addition to any NP Core constraints.