SanteSuite Help Portal
  • SanteSuite Help Portal
    • Disclaimer
  • Product Overview
    • SanteSuite Products
      • Introducing SanteDB CDR
        • SanteDB Solutions
      • Master Patient Index - SanteMPI
      • Immunization Management System - SanteIMS
      • Privacy & Security - SanteGuard
    • SanteDB Versions
  • Architecture
    • SanteDB Architecture
      • SanteDB History
    • Solution Architecture
    • Software Architecture
      • Publish / Subscribe Architecture
      • New ADO (nuado)
      • Roadmap
    • Data & Information Architecture
      • Conceptual Information Model
        • Concept Dictionary
          • Data Dictionary
        • Acts
          • State Machine
          • Act Relationships
          • Mood Concepts
          • Class Concepts
          • Data Dictionary
        • Entities
          • State Machine
          • Entity Relationships
          • Determiner Codes
          • Class Codes
          • Data Dictionary
        • Null Reasons
        • Extended Data
      • Physical Model
        • Act Data Dictionary
        • Entity Data Dictionary
        • Concept Dictionary Data Dictionary
      • Data Storage Patterns
        • Master Data Storage
      • SanteDB Object Identifiers (OIDs)
    • Security Architecture
    • Privacy Architecture
    • Matching Engine
    • HIE & Interoperability
  • Installation
    • Installation
    • Releases
      • 3.0 Releases
      • Queenston Release
    • Quick Start Guide
      • Seeding ONC Patient Matching Data
    • Operationalizing SanteDB
      • Information Gathering & Analysis
      • Planning & Preparation Work
        • Pre-flight Checklist
        • Develop a Business Architecture
        • Develop an Information Architecture
          • Establishing Minimum Datasets
          • Identity Environment
        • Develop Operational Technology Architecture
        • Developing Privacy Impact Assessments
        • Develop Threat / Risk Assessments
      • Deployment
        • Pre-Flight Checklist
        • Installing Software
          • SanteDB iCDR Server
            • Installation on Virtual or Physical Environments
              • Installation on Microsoft Windows
              • Installation on Linux and Unix
            • Installation using Appliances
              • Using Docker Containers
                • Adding Sample Data
                • Feature Configuration
                • SanteDB within Instant OpenHIE
              • Using Virtual Appliances
            • Installation Qualification
              • Master Patient Index / Client Registry Qualification
                • MPI/CR Test Cases for HL7v2
                  • TEST: OHIE-CR-02-HL7v2
                  • TEST: OHIE-CR-03-HL7v2
                  • TEST: OHIE-CR-04-HL7v2
                  • TEST: OHIE-CR-05-HL7v2
                  • TEST: OHIE-CR-06-HL7v2
                  • TEST: OHIE-CR-07-HL7v2
                  • TEST: OHIE-CR-08-HL7v2
                  • TEST: OHIE-CR-09-HL7v2
                  • TEST: OHIE-CR-10-HL7v2
                  • TEST: OHIE-CR-11-HL7v2
                  • TEST: OHIE-CR-12-HL7v2
                  • TEST: OHIE-CR-13-HL7v2
                  • TEST: OHIE-CR-14-HL7v2
                  • TEST: OHIE-CR-15-HL7v2
                  • TEST: OHIE-CR-16-HL7v2
                  • TEST: OHIE-CR-17-HL7v2
                  • TEST: OHIE-CR-18-HL7v2
                  • TEST: OHIE-CR-01-HL7v2
                  • HL7v2 Test Cases Instructions
                • MPI/CR Test Cases for FHIR
                  • TEST: OHIE-CR-01-FHIR
                  • TEST: OHIE-CR-02-FHIR
                  • TEST: OHIE-CR-03-FHIR
                  • TEST: OHIE-CR-04-FHIR
                  • TEST: OHIE-CR-05-FHIR
                  • TEST: OHIE-CR-06-FHIR
                  • TEST: OHIE-CR-07-FHIR
                  • TEST: OHIE-CR-08-FHIR
                  • TEST: OHIE-CR-09-FHIR
                  • FHIR Test Cases Instructions
              • Security Administration Testing
                • Administrative Panel Validation
                  • User Management Tests
                    • TEST: SECURITY-UM-01
                    • TEST: SECURITY-UM-02
                    • TEST: SECURITY-UM-03
                    • TEST: SECURITY-UM-04
                    • TEST: SECURITY-UM-05
                    • TEST: SECURITY-UM-06
                    • TEST: SECURITY-UM-07
                    • TEST: SECURITY-UM-08
                    • TEST: SECURITY-UM-09
                    • TEST: SECURITY-UM-10
                    • TEST: SECURITY-UM-11
                    • TEST: SECURITY-UM-12
                    • TEST: SECURITY-UM-13
                    • TEST: SECURITY-UM-14
                    • TEST: SECURITY-UM-15
                    • TEST: SECURITY-UM-16
                    • TEST: SECURITY-UM-17
                    • TEST: SECURITY-UM-18
                    • TEST: SECURITY-UM-19
                    • TEST: SECURITY-UM-20
                    • TEST: SECURITY-UM-21
                    • TEST: SECURITY-UM-22
                    • TEST: SECURITY-UM-23
                    • TEST: SECURITY-UM-24
                    • TEST: SECURITY-UM-25
                    • TEST: SECURITY-UM-26
                    • TEST: SECURITY-UM-27
                    • TEST: SECURITY-UM-28
                    • TEST: SECURITY-UM-29
                    • TEST: SECURITY-UM-30
                    • TEST: SECURITY-UM-31
                    • TEST: SECURITY-UM-32
                    • TEST: SECURITY-UM-33
                    • TEST: SECURITY-UM-34
                    • TEST: SECURITY-UM-35
                    • TEST: SECURITY-UM-36
                    • TEST: SECURITY-UM-37
                  • Group/Role Management Tests
                    • TEST: SECURITY-GRM-01
                    • TEST: SECURITY-GRM-02
                    • TEST: SECURITY-GRM-03
                    • TEST: SECURITY-GRM-04
                    • TEST: SECURITY-GRM-05
                    • TEST: SECURITY-GRM-06
                    • TEST: SECURITY-GRM-07
                    • TEST: SECURITY-GRM-08
                    • TEST: SECURITY-GRM-09
                    • TEST: SECURITY-GRM-10
                    • TEST: SECURITY-GRM-11
                    • TEST: SECURITY-GRM-12
                    • TEST: SECURITY-GRM-13
                    • TEST: SECURITY-GRM-14
                    • TEST: SECURITY-GRM-15
                  • Security Policy Management Tests
                    • TEST: SECURITY-PM-01
                    • TEST: SECURITY-PM-02
                    • TEST: SECURITY-PM-03
                    • TEST: SECURITY-PM-04
                  • Device Management Tests
                    • TEST: SECURITY-DM-01
                    • TEST: SECURITY-DM-02
                    • TEST: SECURITY-DM-03
                    • TEST: SECURITY-DM-04
                    • TEST: SECURITY-DM-05
                    • TEST: SECURITY-DM-06
                    • TEST: SECURITY-DM-07
                    • TEST: SECURITY-DM-08
                    • TEST: SECURITY-DM-09
                  • Application Management Tests
                    • TEST: SECURITY-AM-01
                    • TEST: SECURITY-AM-02
                    • TEST: SECURITY-AM-03
                    • TEST: SECURITY-AM-04
                    • TEST: SECURITY-AM-05
                    • TEST: SECURITY-AM-06
                    • TEST: SECURITY-AM-07
                    • TEST: SECURITY-AM-08
          • SanteDB dCDR Instances
            • Installing Web Access Gateway
            • Installing Disconnected Gateway
            • Installing Disconnected Windows Application
            • Installing the dCDR SDK
            • User Interface App Settings
        • Configuring Privacy Controls
        • Post Deployment Tuning
        • Securing SanteDB Configuration
        • Securing SanteDB Databases
        • Securing SanteDB APIs
      • Rollout
    • Demonstration Environments
  • Operations
    • SanteDB Operations
    • Server Administration
      • Configuration Tool
        • Messaging Settings
          • HL7 Version 2 Service
          • FHIR R4 Service
          • GS1 BMS XML Service
          • Health Data Services Interface
          • Administrative Management Interface
        • Diagnostics Settings
        • Persistence Settings
          • Retention Policies
          • Resource Manager Settings
          • Database Connections
        • System Settings
        • Performance Settings
        • Security Settings
          • Data Privacy Filtering
          • Auditing Configuration
        • Operating System Settings
      • Server Configuration File
        • Service API Configuration
          • REST Service Configuration
        • Connection Strings
        • Application Service Context Configuration
        • Applet Configuration
        • Diagnostics Configuration
        • Data Quality Services
      • SanteDB iCDR Host Command
      • Backup Procedures
      • Log File Management
    • CDR Administration
      • SanteDB Administration Portal
        • Logging In
        • Managing Your Profile
        • System Administration
          • Jobs
          • Logs
          • Pub/Sub Manager
          • Server Status
          • Dispatcher Queue
          • Probes
        • Reference Data Administration
          • Place Administration
          • Facility Administration
          • Materials
          • Identity Domain Management
        • Concept Dictionary Administration
          • Concept Sets
          • Concepts
          • Code Systems
        • CDR Administration
          • Importing Data
          • Data Quality Rules
          • Extensions
          • Decision Support Library
            • View CDSS Library
            • Edit CDSS Library
          • Matching Configuration
            • Creating / Viewing Configurations
            • General Configuration
            • Blocking Configuration
            • Scoring Configuration
            • Classification Configuration
            • Testing Match Configuration
            • Match Configuration XML Definition
        • Data Warehouse
        • Reports Centre
        • Security Administration
          • Managing User Accounts
          • Managing Groups
          • Managing Policies
          • Managing Devices
          • Managing Applications
          • Reviewing Audits
      • SanteDB Administration Console
        • User Administration
        • Group / Role Administration
        • Policy Administration
        • Device Administration
        • Application Administration
    • Standard Operating Procedures
      • User Management SOPs
        • SOP: Onboarding Users
        • SOP: User Lockout
        • SOP: Deactivating Users
      • Role Management SOPs
        • SOP: Role Policy Assignment
        • SOP: Assigning Users to Roles
        • SOP: Creating New Roles
      • Device Management SOPs
        • SOP: Onboarding new HL7v2 Device
        • SOP: Onboarding new dCDR Device
      • Application Management SOPs
      • Standard Operating Procedure Template
  • User Guides & Training
    • SanteDB User Guides
    • Common User Interface Elements
    • SanteMPI
      • Getting Started with the MPI
      • SanteMPI Matches
      • SanteMPI Searching
      • SanteMPI Power Search
      • SanteMPI Patient Detail
        • Demographics Tab
          • Demographic Information Panel
          • Identifiers Panel
          • Related Persons Panel
          • Entity Relationships Panel
        • Master Data Management Tab
          • Records of Truth
        • Data Quality Tab
      • SanteMPI Dashboard
    • SanteEMR
      • EMR Administration
        • Care Pathways
        • Visit Types & Flows
        • Clinical Templates
    • SanteGuard
  • Developers
    • Extending & Customizing SanteDB
    • Getting Started
    • SanteDB XML Schemas
    • Applets
      • Applet Use and Lifecycle
      • Applet SDK Components
        • Applet Development Environment
        • SanteDB Brain Bug
        • Package Manager
        • BRE Debugger
      • Applet Structure
      • JavaScript API
      • Business Intelligence Assets
        • BI Asset Definitions
          • Data Sources
          • Parameters
          • Queries
          • Reference Data
          • Views
          • Data Marts
          • Reports
          • Indicators
        • BI Render Controls
      • Localization
      • Customization & Branding
      • Assets
        • HTML Assets
        • HTML Widgets
        • Virtual Assets
      • AngularJS
      • Clinical Decision-Support
        • CDSS Definitions
        • Legacy CDSS
      • Business Rules
      • Dataset Files
      • External Data Maps
      • Applet Solution Packages
      • JavaScript API Reference
      • Recipes
        • Adding Security Policy based on Occupation
        • Assigning a Home Facility
        • Codified Address
        • Generating ID on Registration
    • .NET Plugins
      • Plugin Libraries
      • Host Context & Lifecycle
      • Business Model Objects
      • Services & Configuration
        • Configuration
          • Configuration Panels
          • Custom Docker Feature Configuration
        • Passive Services
        • Daemon Services
        • Service Definitions
          • Ad-Hoc Cache Provider
          • Application Identity Provider
          • Audit Dispatch Service
          • Barcode Generator Provider
          • Business Rules Service
          • Care Plan Generation Service
          • CDSS Clinical Protocol Repository
          • Concept/Terminology Provider
          • Configuration Manager Service
          • Daemon Service
          • Data Archiving Service
          • Data Privacy Enforcement Provider
          • Data Signing Service
          • dCDR Subscription Definition Provider
          • dCDR Subscription Execution Provider
          • Device Identity Provider
          • Exec-Once Message Persistence
          • Freetext Search Provider
          • IDataPersistenceService{TData}
          • IDataPersistenceServiceEx{TModel}
          • IDataQualityConfigurationProviderService
          • Identity Domain Provider
          • IDispatcherQueueManagerService
          • IElevatableIdentityProviderService
          • IExtensionTypeRepository
          • IFastQueryDataPersistenceService{TEntity}
          • IFastQueryRepositoryService{TEntity}
          • IPersistableQueryRepositoryService{TEntity}
          • IPubSubManagerService
          • IRecordMergingService{T}
          • IRepositoryService
          • ISecurityRepositoryService
          • ISqlDataPersistenceService
          • IStoredQueryDataPersistenceService{TEntity}
          • ITagPersistenceService
          • ITemplateDefinitionRepositoryService
          • IThreadPoolService
          • IUnionQueryDataPersistenceService{TEntity}
          • IValidatingRepositoryService{TModel}
          • Job Management Service
          • Localization Provider
          • Mail Repository Provider
          • Name Alias Provider
          • Network Metadata Provider
          • Password Hashing Service
          • Password Validation Service
          • Policy Decision Provider (PDP)
          • Policy Enforcement Provider (PEP)
          • Policy Information Provider (PIP)
          • Primary Data Caching Provider
          • Query Result Scoring Provider
          • Record Matching Configuration Provider
          • Record Matching Provider
          • Record Merging Provider
          • Repository Service
          • Repository Service with Cancellation Support
          • Repository Service with Extended Functions
          • Repository Service with Notification Support
          • Resource Checkout/Locking Provider
          • Resource Patching Provider
          • Resource Pointer Service
          • Role Provider
          • Security Challenge Authentication Provider
          • Security Challenge Storage Provider
          • Session Authentication Provider
          • Session Storage Provider
          • Stateful Query Provider
          • Stock Management Provider
          • Symmetric Encryption Provider
          • TFA/MFA Secret Generator
          • User Identity Provider
          • User Notification Relay Provider
          • User Notification Template Filler
          • User Notification Template Repository
      • Plugin Metadata
      • Database Patching
      • Custom Match Algorithms
      • Unit Testing Framework
      • Digital Signing Requirements
      • .NET API Reference
    • Service APIs
      • OpenID Connect
        • Consent & Privacy
      • Business Intelligence Service (BIS)
      • Administration Management Interface (AMI)
      • Health Data Service Interface (HDSI)
        • HTTP Request Verbs
        • HDSI Query Syntax
          • Filter Functions
        • API Responses
        • Patching
        • MDM Extensions for HDSI
        • Synchronization API
        • Visual Resource Pointer API
      • HL7v2
        • Enabling HL7v2 Interfaces
        • HL7 Authentication
        • SanteDB HL7v2 Implementation
      • HL7 FHIR
        • Enabling FHIR Interfaces
        • SanteDB FHIR Implementation
          • FHIR Subscriptions
          • Related Persons
        • Extending FHIR Functionality
      • GS1 BMS XML
      • Examples
        • Connecting to the FHIR API
        • Obtaining A Session
    • SanteDB Software Publishers
  • Knowledgebase
    • Knowledgebase
      • SanteDB 2.1.161+ on PostgreSQL 10 returns "websearch_to_tsquery" error
      • Upgrading SanteDB iCDR with large databases
      • Upgrading Gateway to SanteDB Langley (v2.0.30+) from SanteDB Kelowna and earlier
      • When sending a National Scoped ID in PID-19 (SSN) you receive "AuthorityUuid" missing error
      • After Installing dCDR you receive an error on SecurityUser
      • When logging into the dCDR you are immediately logged back out
      • PostgreSQL connections fail with block message
      • Backing up HDSI server database
      • You receive an "out of disk space" error on the IMS server
      • Setting up the "sherlock" service
      • Diagnosing service port issues
      • You receive a certificate expired or certificate not found error on startup
      • After updating a database field the values are not reflected in the application layer
      • Diagnosing Submission Errors From Mobile Device
      • Migrating A SanteDB Server
      • Pruning and Cleaning the Database
      • Improving Download Speeds on Slow Connections
      • You receive a client already running error message
      • Resetting the configuration of the Windows & Linux Applications
      • After setting up the application data appears to be missing
      • Disconnected Client Window is Scaled Improperly
      • Fatal Error on Startup
      • Synchronization Issues on Mobile
      • Installation on Mono 4.x does not permit joining of realm
      • Creating A Public Backup
      • Installing the SanteDB Disconnected Server
    • Fixes & Patches
      • 20170721-01
      • 20170725-01
      • 20170803-01
      • 20170804-01
      • 20170913-01
      • 20171003-01
      • 20171011-01
      • 20171016-01
      • 20171023-01
      • 20171030-01
      • 20171108-01
      • 20171124-01
      • 20180126-01
      • 20180131-01
      • 20180211-01
      • 20181112-01
      • 20181113-01
      • 20190322-01
      • 20190522-01
      • 20190625-01
      • 20200105-01
  • OpenIZ
    • About OpenIZ
      • Upgrading from OpenIZ to SanteDB
    • FAQ
    • OpenIZ Demonstration Servers
Powered by GitBook
On this page
  • Resource URLS and ID
  • Offsite Resource Links
  • FHIR References
  • Reference By UUID
  • Reference Bundle Object
  • Re-Submission of Unidentified Resources

Was this helpful?

  1. Developers
  2. Service APIs
  3. HL7 FHIR

SanteDB FHIR Implementation

Unlike CDRs which use FHIR as the basis of their data storage throughout the stack, SanteDB treats FHIR as an edge messaging format. Therefore FHIR resource requests are considered transient and are never persisted into the database.

Because of this, there are several implementation notes which are important to remember when interacting with the SanteDB FHIR service handlers.

Resource URLS and ID

When submitting a FHIR bundle, each entry in the bundle may contain a fullUrl property which point to an absolute URL where the resource originated and/or was referenced. For example:

{
    "resourceType" : "Bundle",
    "entry" : [
        {
            "fullUrl" : "http://example.com/fhir/Patient/3",
            "resource": {
                "resourceType" : "Patient",
                "id" : "3"
            }
        }
    ]

In SanteDB this fullUrl is replaced with the internal URL on the SanteDB server once submitted. For example, after submission Patient/3 would carry a fullUrl of http://santedb_server/fhir/Patient/95569551-5abd-4484-be52-4c6986c4beb7 and an id of 95569551-5abd-4484-be52-4c6986c4beb7 .

The FHIR message processor only tracks http://example.com/fhir/Patient/3 in order to resolve references within the same message transaction, this is not stored in the database unless the identifier is a UUID in which case the id element will be used as the suggested UUID for inserting the patient (i.e. update if the UUID exists, or use the UUID if it doesn't).

There are several reasons that SanteDB doesn't store this information:

  1. The fullUrl may be a fully qualified URL, may be an OID, a UUID, or a relative URL which have different semantic meanings in the iCDR instance.

  2. It is nearly impossible to determine if any random client is sendingid from the perspective of itself (i.e. my internal reference for this record is X and I am sharing it with the server), or if it is from the perspective of the iCDR (i.e. I have fetched this resource from you and am using your identifier).

  3. Simple structured identifiers and fullUrls have no concrete meaning , for example SYSTEM_A sending a Patient with a relative URL ofPatient/1 and SYSTEM_B sending Patient/1. The actual record being updated cannot be reliably resolved with ID 1 or even Patient/1 so mis-identification is a serious risk.

  4. While it would be possible to store the fullUrl for an object stored as a bundle, objects submitted via simple POST operations via REST to the SanteDB iCDR instance would not have this contextual identifier, and would merely carry an id element, making referencing the object impossible.

Offsite Resource Links

In FHIR, it is possible to link to clinical data hosted offsite, or on another server. There are several reasons why this is a bad practice:

  • Internal processes within SanteDB wouldn't have information necessary to action the object (such as matching, de-duplication, etc.)

  • There would be no way for the dCDR instances to actually acquire the information to populate the user interface since offsite references assume that an internet connection is available to fetch the resource

  • There is an assumption made that the offsite server will be accessible at all times from all clients which may consume the information, this is often not the case.

  • There is a dependency on another system to be present, the identifier / resource to be valid (not removed as part of a merge/move operation, etc.)

Consider the following request to create a patient

{
    "resourceType":"Patient",
    "name": [
        "use":"official",
        "given": [ "JOHN" ],
        "family": "SMITH"
    ],
    "managingOrganization" : {
        "reference" : "http://some-other-registry.org/fhir/Organization/123"
    }
}

When submitting this resource to the SanteDB FHIR interface, you will receive an error indicating that the managing organization is not known to SanteDB.

{
   "resourceType": "OperationOutcome",
   "id": "8441e711-6d63-426c-95b6-c3289f9866a7",
   "issue": [            {
      "severity": "error",
      "code": "exception",
      "diagnostics": "Could not find http://some-other-registry.org/fhir/Organization/123 as a previous entry in this submission. Cannot resolve from database unless reference is either urn:uuid:UUID or Type/UUID"
   }]
}

You can resolve this by either including the organization information in the submission:

{
    "resourceType" : "Bundle",
    "entry" : [
        {
            "fullUrl" : "http://some-other-registry.org/fhir/Organization/123",
            "resource" : {
                // data fetched from Organization
            }
        },
        {
            "fullUrl" : "http://example.com/fhir/Patient/3",
            "resource": {
                "resourceType":"Patient",
                "name": [
                    "use":"official",
                    "given": [ "JOHN" ],
                    "family": "SMITH"
                ],
                "managingOrganization" : {
                    "reference" : "http://some-other-registry.org/fhir/Organization/123"
                }
            }
        }
    ]
}

Or you can manually register the Organization using the REST api and then including the logical identifier as the resource link or UUID within SanteDB's database:

{
    "resourceType":"Patient",
    "name": [
        "use":"official",
        "given": [ "JOHN" ],
        "family": "SMITH"
    ],
    "managingOrganization" : {
        "identifier" : {
            "system" : "some-known-identity-domain",
            "value" : "some-known-identifier"
        }
    }
}

FHIR References

In FHIR a Reference object is used to link two resources together in a role. This is similar to SanteDB's EntityRelationship class, with the limitation that EntityRelationship does not permit the linking of objects which are not stored within the SanteDB instance.

Reference By UUID

Referencing an object by UUID is the most preferred mechanism of resource referencing. Resources which are linked by UUID are first cross referenced in the current processing scope (the bundle), followed by database linkage. Reference by UUID is commonly represented as:

"someReference" : {
     "reference" : "Patient/bcddb6c7-2892-4b61-aec6-0dbdd718b792"
}

Alternately, if you're not picky about what the reference type is (i.e. it could be any entity, but it is a known entity to SanteDB) you can use a plain UUID reference:

"someReference" : {
     "reference" : "urn:uuid:bcddb6c7-2892-4b61-aec6-0dbdd718b792"
}

You can also reference contained resources using a local reference:

"contained": [
    {
        "resourceType":"RelatedPerson",
        "id":"123"
    }
], 
...
"someReference": {
    "reference":"#123"
}

Business identifier references are also supported by the reference resolver:

"someReference" : {
     "type" : "Patient",
     "identifier": {
          "value": "bcddb6c7-2892-4b61-aec6-0dbdd718b792"
     }
}

Reference Bundle Object

Referencing an object which is being processed within the same scope is also permitted. The reference is subject to the following limitations:

  1. The reference property must exactly match the fullUrl property in the bundle

  2. The reference objects must exist in order , i.e. a RelatedPerson which has a reference of Patient/1 must exist after the Patient with fullUrl of Patient/1 in the bundle

  3. No circular references are permitted (i.e. Patient/2 with link to RelatedPerson/1 with a link to Patient/1 which in-turn links to Patient/2 )

"entry": [
  {
    "fullUrl": "Patient/1",
    "resource": {
      "resourceType": "Patient",
      "id": "1",
      ...
    }
  },
  {
    "fullUrl": "RelatedPerson/1",
    "resource": {
      "resourceType": "RelatedPerson",
      "id": "1",
      "patient": {
        "reference": "Patient/1"
      },
      ...
    }
  }

Re-Submission of Unidentified Resources

Whenever a client system submits an unidentified resource to the SanteDB iCDR FHIR interface, SanteDB will create a new copy of that resource and generate a unique UUID for it. An unidentified resource is a resource which lacks any of:

  • A full UUID as the id element of the resource

  • A business identifier in the identifier element of the resource within a uniquely generated identity domain

For example, consider the registration of a patient and a related person:

"entry": [
    {
      "fullUrl": "Patient/1",
      "resource": {
        "resourceType": "Patient",
        "id": "1",
        "name": [
          {
            "use": "usual",
            "given": [
              "JOHN"
            ]
          }
        ],
        "gender": "male",
        "birthDate": "2017-04-03"
      },
      "request": {
        "method": "POST",
        "url": "Patient/1"
      }
    },
    {
      "fullUrl": "RelatedPerson/1",
      "resource": {
        "resourceType": "RelatedPerson",
        "id": "1",
        "patient": {
          "reference": "Patient/1"
        },
        "relationship": [
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
                "code": "MTH"
              }
            ]
          }
        ],
        "name": [
          {
            "use": "usual",
            "given": [
              "MARY"
            ]
          }
        ],
        "gender": "female"
      },
      "request": {
        "method": "POST",
        "url": "RelatedPerson/1"
      }
    }

Upon sending this bundle to the server, the iCDR will create a new Patient (example: Patient/UUIDA) and a new Person (example: Person/UUIDB) which is related via an EntityRelationship. If a client re-submits this exact bundle, the iCDR will (once again) register a new Patient (example: Patient/UUIDC ) and a new Person (example: Person/UUIDD).

If, however only one of the resources contained a reliable identifier, such as the patient in this example:

"entry": [
    {
      "fullUrl": "Patient/1",
      "resource": {
        "resourceType": "Patient",
        "id": "1",
        "identifier": [
          {
            "system":"http://santedb.org/unique_domain",
            "value":"FHR-4040"
          }
        ],
        "name": [
          {
            "use": "usual",
            "given": [
              "JOHN"
            ]
          }
        ],
        "gender": "male",
        "birthDate": "2017-04-03"
      },
      "request": {
        "method": "POST",
        "url": "Patient/1"
      }
    },
    {
      "fullUrl": "RelatedPerson/1",
      "resource": {
        "resourceType": "RelatedPerson",
        "id": "1",
        "patient": {
          "reference": "Patient/1"
        },
        "relationship": [
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
                "code": "MTH"
              }
            ]
          }
        ],
        "name": [
          {
            "use": "usual",
            "given": [
              "MARY"
            ]
          }
        ],
        "gender": "female"
      },
      "request": {
        "method": "POST",
        "url": "RelatedPerson/1"
      }
    }

Then the behavior is modified such that an initial submission results in a Patient with business identifier FHR-4040 (example: Patient/UUIDA) and a Person (example: Person/UUIDB) related to one another via an EntityRelationship.

If the client resubmits this bundle, the CDR is able to cross-reference the Patient (as it has a business identifier of FHR-4040) and would perform an update (on Patient/UUIDA) however since the RelatedPerson cannot be reliably referenced to a known object, a new Person would be created (example: Person/UUIDC) related to the Patient via an EntityRelationship.

The end state of this message would be:

  • Patient/UUIDA exists with business identifier FHR-4040

  • Person/UUIDB exists and is related via EntityRelationship as the MOTHER of Patient/UUIDA

  • Person/UUIDC exists and is related via EntityRelationship as the MOTHER of Patient/UUIDA

The recommended manner to submit this bundle would be to either give both Patient and RelatedPerson a reliable business identifier:

"entry": [
    {
      "fullUrl": "Patient/1",
      "resource": {
        "resourceType": "Patient",
        "id": "1",
        "identifier": [
          {
            "system":"http://santedb.org/unique_domain",
            "value":"FHR-4040"
          }
        ],
        ...
      },
      "request": {
        "method": "POST",
        "url": "Patient/1"
      }
    },
    {
      "fullUrl": "RelatedPerson/1",
      "resource": {
        "resourceType": "RelatedPerson",
        "id": "1",
        "patient": {
          "reference": "Patient/1"
        },
        "relationship": [
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
                "code": "MTH"
              }
            ]
          }
        ],
        "identifier": [
          {
            "system":"http://santedb.org/unique_domain",
            "value":"FHR-4041"
          }
        ]
        ...
      },
      "request": {
        "method": "POST",
        "url": "RelatedPerson/1"
      }
    }

Or to give each a UUID as their identifier:

"entry": [
    {
      "fullUrl": "Patient/32bdc53f-0908-4e47-990b-43484ffc78bc",
      "resource": {
        "resourceType": "Patient",
        "id": "32bdc53f-0908-4e47-990b-43484ffc78bc",
        ...
      },
      "request": {
        "method": "POST",
        "url": "Patient/32bdc53f-0908-4e47-990b-43484ffc78bc"
      }
    },
    {
      "fullUrl": "RelatedPerson/95569551-5abd-4484-be52-4c6986c4beb7",
      "resource": {
        "resourceType": "RelatedPerson",
        "id": "95569551-5abd-4484-be52-4c6986c4beb7",
        "patient": {
          "reference": "Patient/32bdc53f-0908-4e47-990b-43484ffc78bc"
        },
        "relationship": [
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
                "code": "MTH"
              }
            ]
          }
        ]
        ...
      },
      "request": {
        "method": "POST",
        "url": "RelatedPerson/95569551-5abd-4484-be52-4c6986c4beb7"
      }
    }
PreviousEnabling FHIR InterfacesNextFHIR Subscriptions

Last updated 3 years ago

Was this helpful?

The behavior of the logical id and full URL are aligned with the , it is recommended that production deployments use when referencing objects in FHIR.

FHIR behaviors specified on Logical ID
business identifiers