Key Design Considerations

This page describes the key design considerations for SGCDI.

Identifier Types

To differentiate the various identifier types, we use the following naming convention in identifier.system: https://fhir.synapxe.sg/NamingSystem/<identifier-shortname>

Below is the list of identifier shortnames defined for SGCDI:

  • nric – Patient NRIC

  • hci-code – Institution / clinic HCI code

  • hcsa-code – Healthcare service provider (HCSA) code

  • mcr – Healthcare professional’s identifier in the Medical Council Registration Board

  • dcr – Healthcare professional’s identifier in the Dental Council Registration Board

  • snb – Healthcare professional’s identifier in the Singapore Nursing Board

  • prn – Healthcare professional’s identifier in the Pharmacists Registration Board

  • sequence-no – sequence number tag for each resource instance

  • event-id – Event (Encounter) identifier

  • record-id – Clinical record identifier

  • case-id – Case identifier

  • movement-id – Patient movement identifier

  • investigation-id – Investigation identifier

  • order-no – Investigation order number

  • accession-no – Accession number

  • dispense-id – Medication dispense identifier

  • source-grouping-id – Source grouping identifier

  • dispensing-location-id – Medication dispensing location identifier

  • facility-unit-id – Facility unit identifier

  • referral-id – Referral identifier

  • device-id – Device identifier

  • item-id – Medication item identifier

  • group-no – Group identifier

  • group-sequence-no – sequence number tag within the group

  • mc-no – Medical certificate number

  • procedure-id – Procedure identifier

  • ed-ref-no – Emergency Department reference number

  • workflow-no – Workflow number

  • plan-definition – Used in PlanDefinition resource to specify care program identifiers

  • questionnaire – Identifier of the questionnaire template

Resource Category

If the same resource is used to represent different business objects (for example, the CarePlan resource is used to represent both Enrollment and Health Plan), category is used to differentiate the business object type.

category is also leveraged to store the service type of a CarePlan since this element can hold multiple values.

Naming Convention

A general rule for uri name is https://fhir.synapxe.sg/{ResourceType}/{ShortName}.

  • refers to FHIR resource type, e.g. ValueSet, CodeSystem.
  • refers to the name that is defined by the project.
Type Naming Convention Example
StructureDefinition.url (Profile) https://fhir.synapxe.sg/StructureDefinition/profile-<shortname> https://fhir.synapxe.sg/StructureDefinition/profile-patient
StructureDefinition.url (Extension) https://fhir.synapxe.sg/StructureDefinition/ext-<shortname> https://fhir.synapxe.sg/StructureDefinition/ext-lightDuty
CodeSystem.url https://fhir.synapxe.sg/CodeSystem/<codesystem-shortname> https://fhir.synapxe.sg/CodeSystem/healthplangoal
ValueSet.url https://fhir.synapxe.sg/ValueSet/<valueset-shortname> https://fhir.synapxe.sg/ValueSet/healthplangoal
PlanDefinition.url https://fhir.synapxe.sg/PlanDefinition/<shortname> https://fhir.synapxe.sg/PlanDefinition/healthier-sg-program
Questionnaire.url https://fhir.synapxe.sg/Questionnaire/<shortname> https://fhir.synapxe.sg/Questionnaire/nuhs-emergencycare-adult
Identifier.system https://fhir.synapxe.sg/NamingSystem/<identifier-shortname> https://fhir.synapxe.sg/NamingSystem/nid

Metadata in request payloads

Control header data

All request payloads must include a control header with the following information: source institution, source system, message ID, message sequence ID, and message date/time.

  • If the request payload is a Bundle, the Bundle SHALL carry the artifact metadata at the Bundle level.
  • If the request payload is a single resource, this metadata SHALL be present at the resource level.

The artifact metadata structure is as follows:

id0..1string
id0..1string
id0..1string
extensionC0..0Extension
url1..1uriFixed Value
id0..0string
extensionC0..0Extension
useΣ ?!0..0codeBinding
typeΣ0..0CodeableConceptBinding
systemΣ1..1uriFixed ValuePattern
valueΣ C1..1string
periodΣ C0..0Period
assignerΣ C0..0Reference(Organization)
id0..1string
extensionC0..0Extension
url1..1uriFixed Value
id0..0string
extensionC0..0Extension
useΣ ?!0..0codeBinding
typeΣ0..0CodeableConceptBinding
systemΣ1..1uriFixed ValuePattern
valueΣ C1..1string
periodΣ C0..0Period
assignerΣ C0..0Reference(Organization)
id0..1string
extensionC0..0Extension
url1..1uriFixed Value
valueDateTimedateTime
url1..1uriFixed Value
versionIdΣ0..1id
lastUpdatedΣ0..1instant
sourceΣ1..1uri
profileΣ0..*canonical(StructureDefinition)
securityΣ C0..*CodingBinding
tagΣ C1..*Coding

meta.profile

Every request payload that contains a Bundle MUST include the meta.profile at two levels:

  • The Bundle level
  • The primary resource level (the first entry—typically a Composition, DiagnosticReport, or List)