3.0 Releases

Version 3.0 of the SanteDB iCDR, dCDR and related solutions (SanteGuard and SanteMPI) represent a large series of changes from the 2.2x series. Some of the changes have been incorporated from our Version 3 Roadmap.

Refactored Persistence Layer

The larges and perhaps most impactful change in the version 3.0 is a complete refactoring of the entire persistence layer in SanteDB. This refactoring has allowed the SanteDB 3.0 version not only to use the database much more efficiently, but allows callers on the REST APIs to exert more control over how data is loaded.

Pipeline Loading of Results

The new persistence layer interfaces which load data to/from a data source now return an instance of IQueryResultSet. This is a delay expanded IEnumerable. Whenever a sort is applied, or a key is selected a new instance of IQueryResultSet is wrapped around the original. The database command is only executed when data is read from the reader. This also cleans up the calling structure, for example, in version 2.0 to determine if a record exists or to select a single field:

var exists = persistence.Find(o=>o.UserName == "BOB", 0, 1, AuthenticationContext.SystemPrincipal).Any();

// Executed SQL:
// SELECT * FROM SEC_USR_TBL WHERE USR_NAME = 'BOB' OFFSET 0 LIMIT 1;

var key = persistence.Find(o=>o.UserName == "BOB", 0, 1, AuthenticationContext.SystemPrincipal).FirstOrDefault(o=>o.Key);
// Executed SQL:
// SELECT * FROM SEC_USR_TBL WHERE USR_NAME = 'BOB' OFFSET 0 LIMIT 1;

This pattern forced the persistence layer to load the object just to determine a detection.

In the new pattern this is now alleviated with IQueryResultSet:

var resultSet = persistence.Find(o=>o.UserName == "BOB", AuthenticationContext.SystemPrincipal);

// No SQL is executed

var exists = resultSet.Any();

// SQL Executed:
// SELECT EXISTS 1 FROM SEC_USR_TBL WHERE USR_NAME = "BOB";

var key = resultSet.Select(o=>o.Key).FirstOrDefault();

// SQL Executed:
// SELECT SEC_USR_ID FROM SEC_USR_TBL WHERE USR_NAME = "BOB" LIMIT 1;

Client Controlled Data Loading Strategies

Callers may also instruct to the data persistence layer the type of load strategy to be used when loading data from the database depending on the intended use of the data.

Data load strategies are:

• QuickLoad - Load only core properties, no related entities

• SyncLoad - Load only properties which are needed for synchronization

• FullLoad - Load all properties directly from the data persistence layer

Loading stratgies are controlled by the DataPersistenceContext :

using(DataPersistenceContext.Create(LoadStrategy.QuickLoad)) {
   // Any data events here will only load core properties#
}

This method can also be used to control the way that data is deleted from the database.

Harmonization of Persistence Providers

3.0 introduces new persistence provider which have allowed us to harmonize the dCDR and iCDR persistence layers into a common framework. This means that the iCDR can be run on SQLite, or the dCDR can be run on PostgreSQL!

Customizable Relationship Validation

You can now customize the validation rules used to validate Entity Relationships, Act Relationships, and Act Participations on the REST API. This makes it easier to create custom context-specific relationship types and enforce data persistence layer validation of those rules.

Refactoring of OAUTH Infrastructure

The OAUTH infrastructure has been refactored completed to better adhere to OpenID concepts. This refactoring includes:

• Separation of the grant type into extendable implementations so users can create custom grant flows or override the SanteDB flows more readily

• Separation of token serialization, and encoding allowing for more robust access and identity token passing

• Implementation of standardized MFA secret generation using time and hash based one time passwords.

Harmonization of the dCDR into the iCDR

The interfaces which differentiated the iCDR and dCDR have now been combined into a common platform. This completes the refactoring of Portable Class Library code to a common code base. This means that any iCDR code can run (theoretically) in a dCDR or vice versa. It also means that iCDRs can be synchronized with other iCDR instances.

Data Marts & Pipelines for BI

The BI layer has been refactored to include a new feature allowing applets to define Data Marts. A data mart is a new database (separate from the primary database) which has de-normalized data which can be used for integrating with SanteDB for reporting purposes at the database layer. Uses for data marts include:

• Exposing a simpler set of tables for third party reporting tools to consume (such as PowerBI, Jasper, or Tableau)

• Isolating BI reports from the primary database allowing for better load balancing on the data infrastructure in SanteDB

• Producing regular snapshots of your primary database over time.

BI data marts define a target schema, and data flows to populate that schema witin your applets and are applied on the dCDR and iCDR in the same manner (whether you're using PostgreSQL or SQLite).

User Customizable Data Quality Rules

Previous versions of SanteDB required system administrators to configure the rules in the primary configuration file. SanteDB 3.0 includes a new function which allows for the export, import and synchornization of data quality rules in the user interface. For more information see: Data Quality Rules.

User Customizable CDSS Rules

Previously SanteDB v1.0, and v2.0 required CDSS rules to be written in an XML grammar and to place those into applet files. This process was tedious and meant that adding new CDSS rules was difficult for end-users and administrators. SanteDB 3.0 enhances this by:

• Providing an administrative UI for creating CDSS rules (see: Decision Support Library)

• Providing a new text-based CDSS grammar that is easier for clinical analysts to write (see: CDSS Definitions)

• REST operations to execute CDSS rules against HDSI objects

User Customizable Concept Dictionary

SanteDB v1.0 and v2.0 required importing of concept terminologies via console tooling which was cumbersome and difficult to write. SanteDB 3.0 introduces a new concept dictionary management tooling in the administration panel (see: Concept Dictionary Administration) and includes the ability to bulk create reference terminologies and concept sets via CSV uploads.

CDR Metadata Export

SanteDB v1.0 and v2.0 used Dataset Files to import data between projects and servers, however creation of these files was cumbersome and required manual editing of XML bundles. SanteDB v3.0 now allows export of any result set directly to a dataset file via the $export operation. Additionally, many of the user interfaces in the administrative panel allow for the export of data directly into a dataset from the UI.

Certificate Mapping

It is now possible in SanteDB 3.0 to map any credential (user, application or device) with one or more certificates for either data signatures or authentication. This greatly streamlines the administration of PKI certificates in the SanteDB solution (see: Certificate Mapping)

Improved HDSI Parsing

SanteDB 3.0's HDSI parsing routines have been completely refactored, and allow for many enhanced queries, including:

• Complex guard expressions, for example:

  • A Consumable relationship with at least 2 doses: participation[relationshipType.mnemonic=Consumable&quantity=>2].player=XXXXX

  • Either next of kin or any family member: relationship[NextOfKin|relationshipType.conceptSet.mnemonic=FamilyMember].target.name.component.value=Bob

• URI friendly operators: eq, ne, gt, gte, lt, lte, ap

• Multi-path OR semantics (rather than the default AND semants) - Example: Patient name or Mother's name: name.component.value||relationship[Mother].name.component.value=Maria

Improvements to dCDR

In Version 2.x, the dCDR, while similar in function to the iCDR, was a completely different codebase. Along with harmonizing of the data layer, the SanteSuite team has also harmonized the entire service layer of the dCDR. This means, for example, that the administration console can be connected to a dCDR instance, or, for example, that the web interface can be run directly on the iCDR (we still recommend separating these concerns between iCDR and dCDR). This improvement means it is much easier to write plugins in C# or other .NET technologies.

Built-In Data Import

SanteDB 3.0 introduces a new feature for External Data Maps, which allow developers to specify a simple transform which ingests data from an external file format (CSV, XLS, etc.) and translates data from that external file format into the RIM for import.

The administration panel also includes a UI for Importing External Data to allow administrators to use their UI to import. See: Importing Data

Improved Administration Panel

The administration panel now supports a variety of improvements which make the administration of Places, Facilities, Organizations, and Materials much easier. These improvements allow an adminsitrator to:

• Define a political division hierarchy (which can then be used for structured address inputs)

• Define facility hierarchy, services, schedules, etc.

• Define material classification types, manufacturers, etc.

Improved Identity Domain Controls

Whereas version 2.x only permitted a single identity domain scope and assigner to be allocated to an identity domain, version 3.x allow administrators to specify multiple. Additionally, it is now possible for an administrator to configure whether information from a particular application is authoritative in nature or informative for a particular identity domain.

Better Development Tools

The development of applets has been greatly improved with the new SanteDB.DevTools package. This plugin allows the iCDR to act like the applet debugger in the v2 iCDR. Meaning that you can edit BI reports, business rules, etc. directly in Visual Studio Code and your iCDR instance will load them in real time. We have also added options to the package manager to inspect created packages, making it easier to debug and diagnose packaging issues.