Key Design Considerations

This page describes the key design considerations for SGCDI.

Naming Conventions

A general rule for URI names is https://fhir.synapxe.sg/{ResourceType}/{ShortName}, where:

  • {ResourceType} is the FHIR resource type (e.g., ValueSet, CodeSystem)
  • {ShortName} is the project-defined short name
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/nric

Resource Category

If the same FHIR resource type represents different business objects (e.g., CarePlan is used for both Enrollment and Health Plan), category is used to differentiate the business object type. category can also store service type since the element accepts multiple values.

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 meta.profile at two levels:

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

API Design Approach

The current position is to use a coarse-grained API design (default CRUD first; extended operations only where necessary):

  1. For document-related Compositions (Discharge Summary, ED Notes, OT Notes), use a generic $submit / $retrieve operation, using meta.profile to indicate the specific resource profile.
  2. For discrete data objects (Ordered Medications, Dispensed Medications, Observations, etc.), use default CRUD (Create/Read) for submission and retrieval.

See Composition.$submit for the $submit pattern, and Batch Integration for NDJSON-based batch patterns.

Modular SGCDI: Core + Domain Packs

SGCDI organises profiles into a Core Pack and modular Domain Packs.

Core Pack

Foundational resources required by all conformant systems:

  • Patient
  • Practitioner
  • Organization
  • Encounter

Domain Packs

Pack Included Data Objects
Medication Ordered Medications, Dispensed Medications, Patient Medication List
Diagnostics Lab Order, Lab Result, Radiology Order, Radiology Report, Cardiology Report, Screening Report
Health Programmes Enrollment, Health Plan, Health Plan Goal, Care Report, Questionnaire, Consent, Patient Archetype
Screening Screening Summary, Screening Report, Observation (screening context)
Clinical Documentation ED Notes, OT Notes, Discharge Summary, Summary Notes, Referral
Social Care Allergy, Medical Alert, Procedure, Problem List, Diagnosis, Family History, Risk Assessment
Advance Care Medical Directive, Advance Care Plan
Administrative Appointment, Claim, Coverage, CareTeam

Systems declare pack support in their CapabilityStatement and SHOULD include all profiles within a declared pack.

Outstanding Design Considerations

  1. For ED Notes, the main procedure can have multiple step procedures. The current design is to use partOf element in the step procedure to reference the main procedure. The alternative design is to create an extension in the main procedure to reference all the step procedures. Read more here EDNotes.

  2. Dispensed medications are modelled using MedicationDispense resource. However there are no suitable elements to store the medication start and end date times and the clinician who authorized the medication. The current design is to store both fields in MedicationRequest resource, using effectiveDosePeriod element to store the medication start and end date times and authorizer extension element to store the authorizing clinician. MedicationDispense resource will reference MedicationRequest resource using authorizingPrescription element. Another design consideration is to create two extension elements in MedicationDispense resource to store both data points. Read more here

    Command 'pagelink' could not render: Page not found.

2. Fine-grained vs Coarse grained API design

  1. Current position is to use coarse grained API (use default CRUD first, and create extended operation unless it is necessary)
    1. for document related composition eg discharge summary, ED notes and OT notes, create generic option such as $submit and use Meta.profile to indicate the resource profile
    2. for other discrete data submission, such as Ordered Meds and Prescribed Meds, use default CRUD for submission and update, and possibly introduce new extended operation if current NEHR supports delta update for meds, lab results, events etc.