Disclaimers for SanteSuite Inc.

All the information on this website is published in good faith and for general information purpose only. SanteSuite Inc. does not make any warranties about the completeness, reliability or accuracy of this information. Any action you take upon the information you find on this website and/or in related documents is strictly at your own risk. SanteSuite Inc. will not be liable for any losses and/or damages in connection with the use of the content.

Consent

By using our website and/or related content, you hereby consent to our disclaimer and agree to its terms.

Licenses

Unless otherwise noted, linked from another author, or hosted/linked on a third party site - all content on this site is licensed under the Creative Commons Share-alike + Attribution (CC-BY-SA) 4.0 license.

For more information see -

Welcome to the SanteSuite help portal. This portal provides detailed information about the design, configuration and operation of the SanteSuite family of products.

What is SanteSuite?

SanteSuite is the collection of software solutions built upon the highly scalable and standards compliant SanteDB Clinical Data Repository (CDR). SanteSuite is designed to operate in an "offline-first" fashion, ideal for frequently disconnected, geographically disperse or low-resource environments. SanteSuite products are also platform agnostic and can be run using common open source infrastructure. SanteSuite solutions provide key digital health infrastructure components for regional or national health systems such as Master Patient/Person Index (MPI) (sometimes known as Client Registry), Master Facility Index (MFI), Master Provider Registry (MPR), National Health Identity Management and Immunization Management Systems (IMS).

What is SanteDB?

SanteDB is a general purpose clinical data repository based loosely on the HL7 Reference Information Model (RIM) which we call the Reduced Reference Information Model (RRIM). SanteDB's CDR has four major platform components:

• iCDR - A centralized service for managing data from clinics, tablets, etc. The iCDR provides an implementation of the Reference Information Model (RIM) and offers robust features such as an OAUTH IdP, Audit Repository, versioning, master data management, etc.

• dCDR - We call this one a "baby CDR", and provides disconnected access to SanteDB's functions. The dCDR operates completely on its own and offers almost 75% of the functionality of the iCDR. It is the same implementation of the RIM-based information model, and can operate many of the plugins which are developed for the iCDR.

• dCDR Gateway - The Disconnected Gateway is a specialized version of the dCDR which combines plugins for HL7v2, ATNA, (and in the future FHIR) and allows clinics who are using third party software such as OpenMRS or OSCAR to leverage dCDR features with standards based interfaces.

Topics

SanteDB Act support attribution of the current status of an act using the state machine illustrated in Figure 2.

The states of an act are:

• New : Indicates that the act has yet to be reviewed and//or that business processing rules have yet to be executed.

• Active : Indicates that an act is currently occurring or being actioned. This state is used, for example, if an encounter is still occurring however has not completed.

Entities also support a basic series of states which identify the current status of the entity in the SanteDB data model. Figure 7 illustrates the states of an entity and the valid transitions.

The states of the entity are:

• New : The entity instance was just created, and no processing, storage, or business rules have been executed.

• Active : The entity has been persisted, any necessary review and/or processing has occurred, and the entity record is active.

SantéIMS, a Digital Public Goods Alliance (DPGA) nominated “global good” (https://digitalpublicgoods.net/registry/), is a proven, purpose-built, person-centered, national-scale immunization management platform that supports planning, end-to-end delivery and realtime reporting of any type or scale of mass vaccination program. SantéIMS comes pre-configured with the standard WHO vaccine schedule but can be configured for any type of program, such as pandemic response for COVID-19 vaccination or HIV inoculation. Its unique, fully integrated design and functionality automates end-to-end vaccination workflows, decision support, and stock management, while at the same time seamlessly automates immunization data feedback loops, aggregate reporting and analytics from local clinic to regional and national levels and beyond. This complete, dedicated vaccination workflow solution has demonstrated significant improvement in efficiency of administering vaccine clinics, simplifies training requirements for staff operating a clinic, speeds up interactions with patients and provides a near real-time national dashboard view of vaccination activity from local clinic to regional and national levels. A purpose-built immunization system such as SantéIMS also enables the implementation of advanced clinical workflows, clinical decision support rules and computable guidelines not often found in general purpose EMRs.

SantéIMS comes pre-configured with the complete WHO vaccine schedule as default, however the schedule and clinical guideline rules are completely customizable to local country or regional needs. SantéIMS supports new clinical workflows such as COVID-19 protocols and can easily be configured support emerging immunization workflows such as HIV and malaria. SantéIMS’s first version (OpenIZ) was funded by PATH (www.PATH.org) in 2016 as part of the Better Immunization Data (BID) initiative and is currently nationally deployed in Tanzania as the Tanzania Immunization Registry (TImR).

SanteDB releases have two versions associated with them:

• Semantic Version -> Which is used for determining compatibility of assemblies within the SanteDB solutions, dependencies, etc.

• Informational Version -> Which is used to describe the overall release.

Versioning Information (1.x and 2.x)

Semantic Versions

The semantic versions of SanteDB look similar to this:

Where:

• Major: Describes the major release.

  • Even numbered major versions are release versions

  • Odd numbered major versions are development versions between releases

Legacy Versions (1.x)

SanteDB originally was implemented as a revision of the core OpenIZ backend. This was implemented on .NET Framework 4.5.2, Xamarin and PCL Profile7 assemblies. These versions begin with the major revision 1.x , ending 1.128.0 (Iqaluit).

Since PCL has been deprecated for some time, a refactor of the code to .NET Standard 2.0 was recently performed.

.NET Standard Versions (2.x)

Starting with SanteDB named version Jasper , the entire shared assembly infrastructure has been ported to .NET Standard 2.0. Since these assemblies are incompatible with the PCL infrastructure and .NET 4.5.2, the entire project was upgraded to .NET 4.7 and the major version rev'd to 2.x series.

Version 3.0

SanteDB version 3.0 and its related solutions (SanteMPI 3.0, SanteIMS 3.0, SanteEMR 3.0) have many enhancements which improve the efficiency and maintainability of SanteDB products. These features are documented in detail throughout the wiki and tagged with:

In summary the enhancements are detailed in

SanteMPI is a next generation, fully functional, open-source and standards-compliant Client Registry that was originally developed to support the Canadian national digital health program beginning in 2006. SanteMPI has been enhanced and refined over decades of investment from governments, private sector companies and non-governmental organizations. SanteMPI has been designed to support the longitudinal management of patient data in jurisdictions around the world and has several proven field deployments in low and middle income countries.

A Master Patient Index (MPI), sometimes called a Client Registry (CR), is a foundational piece of any regional or national health system. Fundamentally, a MPI solution seeks to create a single master list of patients across a jurisdiction and to provide a cross-reference of the various identifiers used by local systems in a region to identify a patient. For example, if a patient is registered in Hospital A as patient number 123 and is registered in Primary Clinic B as patient number 456, a Master Patient Index configured in the region will keep track of these various identifiers and provide a list of them to any system on demand. This enables health care providers to see a "longitudinal view" of a patient, that is, all interactions of the patient with various components of the health care system over time.

SantéMPI is a fully functional, national scale, open-source, and standards-compliant Master Patient Index (MPI) / Client Registry (CR) designed for regional and national health system use. SantéMPI was originally developed as a reference implementation to support the Canadian national digital health program administered by Canada Health Infoway (infoway.ca) beginning in 2006. SantéMPI has been enhanced and refined over decades of investment from various government agencies, private sector companies and non-governmental organizations. SantéMPI has been designed to support the longitudinal management of patient data in jurisdictions around the world and has several proven field deployments in low and middle income countries. SantéMPI has proven to be secure, scalable, reliable, performant, fully featured, standards-compliant, inexpensive and easy to support.

The SantéSuite team that developed SantéMPI have also made significant contributions to the underlying international standards used for MPI/CR systems, including the HL7 v2/v3 and HL7 FHIR standards, the OpenHIE Architecture Specification Client Registry solution, and the IHE patient identity mobile profiles (PIXm and PDQm). These contributions have enhanced the standards to allow for the efficient unique identification of patients even while using low resource mobile devices.

SantéMPI implements all existing interoperable specifications and requirements related to Client Registry in the OpenHIE specification. SantéMPI is fully compliant to operate within a health information exchange (HIE) environment as a Client Registry. SantéMPI has been field tested with millions of successful transactions in multiple jurisdictions, and can operate standalone or as a launching point into a health information exchange. By implementing both modern HL7 FHIR standards and the widely deployed existing legacy HL7v2 standards, SantéMPI provides a platform for integrating existing solutions and future solutions. In this context, SantéMPI has demonstrated integrations with WorldVistA EHR, OpenMRS and OSCAR EMR.

SantéMPI leverages the unique online/offline capability and data architecture of SantéDB by building on our lessons learned developing and implementing the MEDIC CR, especially in low resource environments. SantéMPI meets the stated functional requirements of the OpenHIE Specification for a client registry. Key features of SantéMPI that directly address these requirements include:

Online/Offline Capability – Leveraging SantéDB’s Disconnected Clinical Data Repository (dCDR), SantéMPI is unique in being able to operate offline when and where needed via an online/offline MPI gateway to/from a centrally hosted server or cloud hosted CR service. Clients on the offline gateway can use HL7 v2.5 or HL7 FHIR to perform MPI functions while offline. This offline capability has been proven to be incredibly important in low resource environment where brownouts, blackouts and lack of connectivity situations are commonplace.

Privacy & Security by Design – SantéMPI leverages the SantéDB CDR, which implements a robust privacy and security solution allowing for access control and privacy controls based on role, device, and third-party application via a policy based access control scheme. Security and Privacy are designed into the solution, not bolted on as an afterthought.

Interoperability Standards Support – SantéMPI supports a variety of standards for patient registration including IHE PIX/PDQ (for HL7v2) and HL7 FHIR. It also provides a completely open API for further extension. The SantéSuite team has made significant contributions to health information standards, including being early contributors to HL7 FHIR, as well as authoring the IHE profiles for mobile access to patient identifiers and this platform has previously passed IHE and HL7 Connectathons.

Probabilistic Matching – SantéMPI leverages a customizable record linkage algorithm for detecting whether two or more existing records are the same.

Master Data Management – SantéMPI provides basic master data management functionality, allowing a single record of truth to be synthesized from data submitted from local sources.

Administration Management – SantéMPI provides extensive administrative user interfaces to provide a robust administrative solution.

Mobile Registration App – A mobile registration app has been developed to support search and registration of patients in real time in the field, offering the ability to issue a health identifier to a new client. This app also leverages QR codes as temporary health identifier for easy generation and recognition of a health identifier.

SanteMPI bundles together existing functions of SanteDB (MDM, Matching, Entity Linking, etc.) and exposes additional logic on top of those interfaces to ensure it is a PIX/PDQ compliant product. SanteMPI works in both the SanteDB iCDR and the dCDR, that's right, you can run a mini-MPI offline in a local clinic between systems.

Related Topics

The SanteDB Clinical Data Repository (CDR) is designed for large-scale regional/national digital health applications. Solutions running on SanteDB may be deployed in dozens, hundreds or even thousands of clinics across a widespread region. In these scenarios, there will be times where individual clinics or points of service will lose connectivity, and this is especially true in geographically sparse and/or low resource environments. SanteDB was designed from the ground up to support this highly distributed scenario and is equipped with a robust synchronization engine that allows individual clinics to go online and offline as they require, while still allowing users to continue to work in their applications without being uninterrupted and without losing any clinical data. When clinics are able to re-establish connectivity, all transactions are synchronized seamlessly between local data stores and the central repository. Each remotely deployed application instance (for example in a clinic, mobile, or anywhere "out on the field") maintains a local version of SanteDB referred to as the distributed clinical data repository or "dCDR". The main central clinical data repository is referred to as the integrated clinical data repository or "iCDR". There is no predefined limit as to how long dCDR apps are able to work offline before they reconnect with the iCDR.

SanteDB solutions run on top of the CDR and are pre-configured, pre-packaged plugins which extend SanteDB to provide a solution to a clinical problem. SanteDB has several solutions targeted to individual clinical domains and use cases, including national health identifiers, master patient index/client registry solutions, national immunization planning and tracking solutions, a distributed EMR and more. The following diagram illustrates how applications make use of SanteDB by extending the base functionality of the SanteDB Core:

• SanteGuard : The SanteGuard solution is a complete audit repository solution. The SanteGuard solution contains:

  • .NET Based Plugins for the SanteDB dCDR and iCDR which allow SanteDB to accept IHE ATNA messages.

  • Applet Widgets which extend the other SanteDB solution user interfaces to add detailed auditing information for system administrators.

  • Extended data storage schemas and plugins to store information related to audit log review workflows.

• SanteEMR : The SanteEMR solution is a framework which provides basic EMR functionality such as scheduling, registration, patient management, clinical templates, etc. Included:

  • Patient Registration and Search Management Workflows

  • Clinical Templates for birth, death, and basic primary care events.

• SanteIMS : The SanteIMS solution provides extended user interfaces and clinical protocol support related specifically to immunizaiton clinics. Included in SanteIMS:

  • Stock management functionality including adjustments, current balances, and order/fulfillment

  • Pre-built clinical decision support related to immunization activities.

• SanteMPI : The SanteMPI solution provides a combination of pre-configured plugins for the SanteDB CDR to work as an MPI. Inlcuded:

  • .NET based plugins which modify the behavior of the HL7v2 and FHIR interfaces to implement IHE PIX, PDQ constraints.

  • Plugins for name aliasing

These solutions provide a basis for community extensions to create branded versions of the underlying applications.

What is SanteDB?

SanteDB is the foundational clinical data repository (CDR) developed by SanteSuite Inc. and leveraged by SanteSuite products. SanteDB is standards-based and highly scalable and is designed for large-scale (regional and national) digital health application deployments.

SanteDB forms the core of the SanteSuite product line and provides a robust, secure, repository for modeling and sharing clinical data.

Features

Although each of the products built upon SanteDB provide the most clinical value, the platform itself provides the fundamental building blocks required to create disconnected, intelligent health applications. Features of SanteDB include:

• Openness

  • 100% Open Architecture, any application can play in the SanteDB ecosystem.

  • Core platform components and community applets are openly documented and source code provided.

SanteDB solutions such as SanteMPI, SanteIMS, and the generic CDR are installed in a similar manner. This section provides resources on the planning, preparation, installation and securing of SanteDB iCDR and dCDR software packages.

Installation for Development

When installing SanteDB in a development environment, we recommendfor your iCDR instance and then .

You can then and follow the article to start developing SanteDB applications!

Production Deployments

Installing SanteDB in a production environment is an involved process which is dependent on the nature of the environment (hospital, province, national, etc.) as well as the specific requirements of the project management office involved.

The SanteDB has collected a high-level guide to the deployment of the SanteDB services like SanteMPI in our guide.

Related Topics

Determiner codes are used to classify whether a tuple in the entity table represents an actual thing or a classification of things. There are three types of determiner classifications for objects listed in .

Additionally, Acts are classified by Mood via the MoodConceptId. The mood of an act identifies the mood or method of operation of the act, moods include:

SanteDB software packages support many different environments and use cases. The underlying software is attempting to provide a common structure into which data/processes can be realized. Because of this there are two different distributions of SanteDB software, which can be installed in an operational environment.

iCDR - Integrated CDR

The iCDR is typically installed once per application role in a jurisdiction. (See:).

dCDR - Disconnected CDR

The dCDR is installed on the client side or in an aggregate setting as a gateway (or mini CDR). The distribution of the dCDR software and its installation is unique to each platform. This wiki covers the configuration of the dCDR to an iCDR instance.

A SanteDB deployment is not like installing Microsoft Office, or a video game. SanteDB is responsible for storing very sensitive personal health information (PHI) and the deployment of SanteDB in any role (MPI, MFR, MPR, SHR, etc.) warrants careful planning and consideration.

This section will guide your through some of the common planning activities that should be undertaken prior to deploying any of the SanteDB solutions/components in your environment.

Contents

These test cases are based on the OpenHIE CR tests for HL7v2 transactions, and contain specific hints for SanteMPI.

Security Configuration

All tests for HL7v2 should ensure they are using either:

• Node authentication - Meaning that an X.509 certificate environment has been configured on the MPI. Note that all device configurations should map the certificate to the credential for the device.

• - Meaning that MSH-8 should carry necessary authentication information to authenticate the sending node.

For more information on how HL7v2 messages are authenticated in SanteDB, please consult the wiki article.

What is SanteGuard?

SanteGuard is a plugin to SanteDB that integrates a powerful audit trail into the SanteDB system. SanteGuard provides several system interfaces, user interfaces, reports, and an enhanced implementation of the IAuditRepository service. At a high level, SanteGuard:

• Allows SanteDB to receive Audit events from external systems using IETF RFC3881 or NEMA DICOM format audits over SYSLOG (TCP, UDP, and STCP).

Operationalizing SanteDB (or any SanteDB solution) is not a trivial task, any large scale deployment of the solution requires planning and coordination between stakeholders. Implementers are encouraged to use formal methodologies for enterprise projects and architecture (examples: , , , etc.) to manage the operationalization of the MPI projects.

Because operationalization is specific to the problem domain, local jurisdiction, size requirements, and other factors, the SanteDB wiki merely provides high level activities for operationalization as a reference. Any of the articles or templates found on the SanteSuite wiki are expected to be adapted by implementers, or to provide SanteDB specific considerations within their existing project management methodology.

The overall operationalization of a SanteDB service can be illustrated with 5 major activities.

Often time acts are related to one another via the ActRelationship entity. Act relationships are important, as typically acts cannot be standalone. For example, one cannot simply “Observe” something without having an encounter. An example of several types of interactions within SanteDB are described below:

1. Patient Presents to receive an Immunization: In this use case the primary act is a PatientEncounter whereby participants include the clinician performing the vaccination (performer), the patient (record target), the clinic (service delivery location). The patient may be weighed prior to receiving the immunization that represents a component act of type Observation, and the administration of the vaccine represents a substance administration with relations to one or materials administered

You can install SanteDB iCDR on Microsoft Windows or Linux / Unix operations on x86 or ARM. The option to install SanteDB iCDR services on a full operating system is well suited for environments where:

• There is a need to finely tune the SanteDB configuration files

• There is a predefined TRA and PIA process which requires hardened / vetted operating system installations.

• There is existing Operating System environments in place, examples include:

SanteDB is designed to have a common . Because of this, it is important that any jurisdiction adapt this model for their local context, and establish a common understanding of the information which will be captured, shared, and stored in the SanteDB instance.

• Develop a minimum dataset for data elements in the CDR, establish common use and definitions, common mappings within the context (i.e. what constitutes a "valid" patient record?)

• Identify the identity which can be used in the CDR instance (how are patients identified? how are immunizations identified? etc.) this includes:

This page provides a convenient pre-flight checklist to ensure that you have sufficient assets in place to proceed with planning your deployment of a SanteDB solution.

• Consensus and Commitment Obtained relevant stakeholders

SanteDB with the MPI plugin (SanteMPI solution) supports the following interfaces for integration:

• IHE Patient Identity Cross Referencing for HL7v2 (IHE PIX)

• IHE Patient Demographics Query for HL7v2 (IHE PDQ)

• IHE Patient Identity Cross Referencing for Mobile (IHE PIXm)

Deployment of SanteDB onto any infrastructure will first involve the the setup of underlying infrastructure assets. SanteDB can run on:

• Modern Linux Distributions (installer is written for Ubuntu)

• Docker Containers

• Microsoft Windows Operating Systems

SanteDB, SanteIMS and SanteMPI are interoperable software solutions for managing clinical data. While a software solution is a means to implement business use cases, it is not the end in itself. Typically the software implements or realizes business processes.

It is important, therefore, to develop a business architecture which describes the human and organizational architecture. This includes:

• Documenting new business processes to be used in clinic among the various connected systems.

• Document data capture standards, and agreement between organizations on the format and use of each data element (establish a common understanding of data elements from a business use).

Acts in the SanteDB data model represent actions taken by entities to other entities. In this lens, we can say that an act represents everything that “happens” to entities. This mechanism of storage allows the SanteDB data model to adapt to different jurisdictions with relative ease.

There are five different types of acts that are supported by the default SanteDB schema (Figure 1).

• Patient Encounters: Represent an act whereby a patient presents, or is intended to present for care.

• Observations: Represent an act whereby an entity observes something. Observations can include codified observations such as diagnoses, textual values such as a free-text description of an event, or a quantity such as weight or heart rate.

Resources

The SanteDB team has provided a template which lists all the data elements captured in SanteDB for Patients, Places, Organizations, and Persons.

To complete this worksheet:

1. Review the readme for the meaning of each column and type of data which should be present.

The SanteSuite community provides ready to deploy virtualization containers for users who wish to use them. Using these images and appliances is well suited when:

• A basic installation of SanteDB iCDR is required to perform an evaluation

• Development, training or testing environments are desired.

• The organization already leverages Docker or Virtualization environments, or does not require vetting/validation of underlying operating system configuration.

• Small installations or localized installations of the software are desired

• Users are deploying to Software-as-a-service (SaaS) environments and need to quickly roll out instances of the SanteDB infrastructure.

One of the benefits of using an appliance over a native or virtual operating system environment, is the bundling of pre-requisites within the deployment.

SanteDB's iCDR and dCDR platforms are designed to operate like any regular CDR. By default, when you install SanteDB's CDR software, the solution will permit the storage and retrieval of the data. This method of operation is sufficient for deployments where SanteDB is servicing a single purpose, for example: a national immunization registry, where only SanteDB is contributing data to / from the central server.

However, when you want to run SanteDB as an integrator of data (for example, as an MPI or a Shared Health Record (SHR)) this mode of operation is no longer optimal. In the field you will have multiple data sources contributing a variety of information.

SanteDB ships with a matching engine that operates in either deterministic or probabilistic modes, these functions are described in the Matching engine documentation. However, once a match is detected, one of two storage patterns can be used.

Single-Instance Mode

When SanteDB's SIM data storage pattern service is enabled, the SIM service will handle the matching and merging of records. In single instance mode, SanteDB's storage engine will flag duplicates (or merge them, depending on your configuration) however will only ever keep one copy of a known good record.

This means, for example, if one system reports a Facility Registration for a facility name "Good Health Hospital", and another reports a facility "Good Health Hospital" that is determined to be a duplicate, SanteDB will flag the two records as duplicates. Once merged, one record is subsumed into the other, the subsumed record is nullified and no longer appears in searches.

Multi-Instance / Master Data Management Mode

When SanteDB's MIM data storage pattern service is enabled, the behavior of the software is quite different. In MIM mode, SanteDB will store all records as a "local" record and tag them as mdm.type=L. The solution then searches for other records which might be duplicated in its data store.

If SanteDB determines no other records match the local record created, it will generate a new master record and tag it as mdm.type=M. Master records aren't really records, rather they are pointers (or an anchor point) where local records are attached.

If the matching system determines that there are potential matches, depending on configuration, it will either link the newly inserted local record to the existing master record which matches, or it will simply mark the record as a candidate local (for later merging).

The sending system has complete authority to update its local records however it wants, it may change names, dates of birth, etc. When an update occurs on a local, the MIM pattern service will re-run the matching rules to determine if the local is still, indeed a match with the master, or if the record could be linked to another master.

When in MIM mode, and a query is run, the MIM persistence service will query for local records which match the specified criteria, and will synthesize a master based on the data elements the requesting system has appropriate access permission for.

Multi-instance mode is very useful for central registries like MPI, MFR, and MPR. It has several benefits over SIM:

• Merged records can subsequently be un-merged

• It is possible to flag / compartmentalize local records based on their access policies (for example, you can prevent an immunization registry from seeing an HIV programme information)

• It allows complete versioning and tracking of updates made to the local record.

Records of Truth

When running in MIM mode, it is possible to assign attributes of the various local records into a record of truth. For example, if you collect patient information from several hospitals about a particular patient (say: William Butler in hospital A, Bill Butler from hospital B), it is possible to designate an official record of truth for that patient. A record of truth will always be returned to callers, and prevents the synthesizing of master data records (or rather, it overrides the local fields which have been promoted to record of truth status).

Records of truth cannot be edited by local systems, records of truth can only be edited by the iCDR in which the record resides.

SanteDB iCDR and dCDR supports basic subscription management. This facility allows external parties to subscribe (via a subscription) to data persistence events, at which they they will receive a notification (via a channel) using one of the available dispatch formats.

The components of the publish and subscribe architecture are:

Publish/Subscribe Manager Schema

The PubSubManager stores data for subscriptions and channels in a concise schema.

Subscriptions

Subscriptions are defined with a target resource (such as Patient, Act, Entity, Person, Place, etc.). The subscription defines one or more events and a series of filters which will trigger the issuance of a notification to the receiver.

The following notification events can be subscribed.

Channels

A channel defines the mechanism to notify the receiver of the publish notification. The channel specifies the endpoint URL (mailto:, sms:, http:, llp:, etc.) the dispatcher to be used, and any settings. Settings are stored as key/value pairs which, depending on the dispatcher will be used to determine the channel format, authorization, etc.

The persistence layer in SanteDB is largely a maintenance codebase of the OpenIZ persistence layer, which itself was originally written in 2009 for the MEDIC CR and MEDIC SHR. This data layer has over a decade of modifications, changes, etc. to it from a variety of authors during its lifetime.

This has lead to several performance issues with SanteDB, namely:

• The intended use of the OpenIZ persistence layer was for synchronization, so objects are deep-loaded in the persistence layer, regardless of whether the caller will use the information. There was no way for the caller to convey to the persistence layer that loading data is not needed.

• The persistence layer requires joining of non-versioned attributes to load data (i.e. versioned attributes and non-versioned attributes were stored as a master/detail view). This impacts query performance as the database needs to perform an extra join.

• There have been several technology enhancements to the .NET platform since the original design of the persistence layer which would optimize the manner in which database calls can be made.

• Missed properties via .LoadProperty() require duplicate hits to the database, regardless if the data persistence layer already made this query and determined there was no matching entries.

To fix this, a new persistence layer (on branch feature/nuado ) has been in development for several months. This new persistence layer:

• Performs lazy-loading of records from the database when the caller requests them (i.e. calling Skip(), Take(), Count(), etc. translates directly to SQL statements in the database rather than deep loading

• Allows the caller to use the QueryPersistenceContext to control the manner in which properties are loaded based on the caller's use case.

Query Result Set

The new persistence layer modifies all the data access classes to use the IQueryResultSet<T> interface. These interfaces support methods for skipping and taking records from the underlining data store in a method which reduces the data loaded from the SQL database.

The code below illustrates the modification of the SQL statement sent to the database by using the result set methods.

Additionally, the application of any data modification processes (such as MDM or policy enforcement) is pipelined. This means that as records are read from the database, each record is operated on by the interested services.

Result Set Implementations

Whenever submitting data to SanteDB's CDR where an element is marked as required, you may submit a null reason (also known as a null flavor). The allowed null flavors are:U

This test ensures that the receiver is able to merge patient data from an assigning authority (TEST_A) which has an national identifier (not assigned by central authority as a PID). The demographics data does not match, this is to test that matching is done on explicit identifiers.

Setup the receiver such that OID 2.16.840.1.113883.3.72.5.9.2 has assigning authority of TEST_A which can be assigned from TEST_HARNESS_A

Setup the receiver such that OID 2.16.840.1.113883.3.72.5.9.B has assigning authority of TEST_A which can be assigned from TEST_HARNESS_B

Setup the receiver such that OID 2.16.840.1.113883.3.72.5.9.9 has assigning authority of NID

Perform necessary steps to ensure that the receiver is configured to merge patients based on the SSN field (PID-19)

Test Step 1:

Test harness (as TEST_HARNESS_A) sends a registration message for patient Yannick Jones having a date of birth to the month, with NID of NID-000345439 and local identifier of TEST_A of RJ-460.

Expected Behaviour

• Receiver Accepts Message with an AA

• MSH-5 and MSH-6 matches “TEST_HARNESS_A|TEST”

Test Step 2:

Test harness (as TEST_HARNESS_B) sends a registration message for patient Yan Jones having a more specific date of birth, with NID of NID-000345439 and local identifier of TEST_B of RB-469.

Expected Behaviour

• Receiver Accepts Message with an AA

• MSH-5 and MSH-6 matches “TEST_HARNESS_B|TEST”

Test Step 3:

Test harness verifies the record from TEST_B is linked with TEST_A via the NID

Expected Behaviour

• Receiver responds with an AA

• Receiver sends exactly one PID segment with identifier RJ-449 in domain TEST_A in one of the PID-3 repetitions

SanteDB is designed with a variety interoperability interfaces and standards, including:

• HL7 Version 2.3 and Version 2.5 messaging

• HL7 FHIR

• GS1 BMS 3.3

• IHE ATNA / UDP

• OpenAPI / Swagger 2.0 Metadata Exchange

Each of these interfaces are enabled/disabled based on the role that SanteDB is operating in. For example, if SanteDB needs to act as an MPI then the GS1 and ATNA interfaces are disabled (along with related user interface platforms).

In this test, the test harness will register a patient with a local identifier (TEST domain). The receiver is the assigning authority for the ECID domain and should generate an ECID by whatever means the software performs this task. The test harness will then ask the receiver to do a cross reference between the TEST domain and the ECID domain. This test ensures that the receiver adheres to the “What Domains Returned” query parameter.

References

Pre-Conditions / Setup

Setup the receiver so that OID 2.16.840.1.113883.3.72.5.9.1 has assigning authority of TEST

Setup the receiver so that OID 2.16.840.1.113883.3.72.5.9.9 has assigning authority of NID

Ensure a patient with the following information is registered in the receiver:Name: Betty Boop, ID: RJ-444 in domain TEST, DOB: 1935This can be registered by sending the following message to the recipient:

Test Step 1:

Test harness requests the receiver to explicitly give it the TEST domain identifiers by sending:

Expected Behaviour

• Receiver Accepts message with an AA

• QAK of OK

• Response message contains exactly one PID segment

• PID contains exactly one PID-3 having:

Test Step 2:

Test harness requests the receiver to explicitly give it the domain identifiers from an invalid domain (RANDOM) by sending:

Expected Behaviour

• Receiver rejects the message with an AE

• Receiver indicates query error with QAK of AE

• Receiver indicates the error with ERR having QPD^1^4

Test Step 3:

Test harness requests the receiver to explicitly give it the domain identifier from a valid domain (NID) for which no identifiers have been associated with the patient by sending:

Expected Behaviour:

• Receiver accepts the message with AA

• Receiver indicates no data found with QAK of NF

• No PID segments are sent in the response message.

In this test, the test harness will register a patient with a local identifier (TEST domain) and will subsequently query the receiver to retrieve the identifiers linked to the newly registered patient.

References

Pre-Conditions / Setup

Setup the receiver so that OID 2.16.840.1.113883.3.72.5.9.1 has assigning authority of TEST

Setup the receiver so that OID 2.16.840.1.113883.3.72.5.9.9 has assigning authority of NID

Test Step 1:

Test harness sends PIX query for identifier RJ-443 (an un-registered patient) and validates the receiver behaves appropriately.

Expected Behaviour

• Receiver accepts the message with AE

• Receiver conveys no data found with AE in QAK

• Receiver indicates error by sending an ERR segment with QPD^1^3^1^1

Test Step 2:

Test harness sends PIX query for identifier RJ-443 (an un-registered patient) in domain RANDOM (an un-registered) domain

Expected Behaviour

• Receiver rejects the message with AE

• Receiver conveys query error with AE in QAK

• Receiver indicates error by sending an ERR segment with QPD^1^3^4^1

Test Step 3:

Test harness sends ADT^A01 message registering a patient.

Expected Behaviour

• Receiver Accepts Message with an AA

• MSH-5 and MSH-6 matches “TEST_HARNESS|TEST”

Test Step 4:

Test harness ensures that patient was registered by executing:

Expected Behaviour

• Receiver Accepts message with an AA

• Response message contains exactly one PID segment

• QAK of OK

• PID-3 of PID segment contains an identifier having:

This test ensures that the receiver is able to merge patient data from an assigning authority (TEST_A) which has an national patient identifier (assigning authority NID). The demographics data does not match, this is to test that matching is done on explicit identifiers.

References

Pre-Conditions / Setup

Setup the receiver such that OID 2.16.840.1.113883.3.72.5.9.2 has assigning authority of TEST_A which can be assigned from TEST_HARNESS_A

Setup the receiver such that OID 2.16.840.1.113883.3.72.5.9.9 has assigning authority of NID which can be assigned from NID_AUTH

Ensure that the following patient is registered in the receiver (can be done with the ADT message provided). Name: John Smith, id: NID-000345435^^^NID^NNXXX, gender: M, dob: 1980

Test Step 1:

Test harness (as TEST_HARNESS_A) sends a registration message for patient Jon [sic] Smith having a more specific date of birth, with NID of NID-000345435 and local identifier of TEST_A of RJ-449.

Expected Behaviour

• Receiver Accepts Message with an AA

• MSH-5 and MSH-6 matches “TEST_HARNESS|TEST”

Test Step 2

Test harness verifies the record was linked with the NID by executing a PIX query

Expected Behaviour

• Receiver responds with an AA

• Receiver sends exactly one PID segment with identifier RJ-449 in domain TEST_A in one of the PID-3 repetitions

Security Threat and Risk Assessment What are Security Threat and Risk Assessments (TRAs)?

A Threat Risk Assessment (TRA) is the overall activity of assessing and reporting security risks for an information system to help make well informed risk-based decisions. A TRA also documents risk ratings and planned treatments of the risks.

Each risk assessed must consider the likelihood to which a threat may leverage a weakness, the potential impact, and an acknowledgement of what this could mean to the organization. The criticality of an information system and security classification of information stored and handled by the system should be reviewed and considered when conducting a TRA. For each risk that is identified, a planned treatment or acceptance must be documented. Risk findings from the TRA activity should be communicated to the appropriate project sponsors and stakeholders.

TRAs should be completed for new or significantly modified information systems and during planning, development and implementation of an information system. A review and updated TRA should be conducted throughout the life of an existing information system for any significant or material change(s) and must also consider any previously identified risks. For critical systems, a review schedule should also be maintained to ensure that TRAs are periodically conducted throughout the life of an information system.

Each jurisdiction will have a unique security threat landscape and may have specific requirements for TRAs, but we have provided a sample TRA template here that should at least help to start the security conversation in your project.

As always, before making use of any of our resources, please read and accept our disclaimer:

The SanteDB conceptual data model is based on several different resources:

• HL7 Reference Information Model (RIM) forms the basis of the core clinical storage engine. SanteDB's implementation keeps the paradigm of Entities Participating in Acts, however removes many of the complex datatypes.

• HL7 FHIR forms the basis for the conceptual data model's extension and tagging capabilities, which are used to extend the SanteDB data model.

• OpenMRS Concept Dictionary was used as the basis of SanteDB's concept tables.

Clinical Data

Clinical data in SanteDB is represented as Entities playing Roles Participating in Acts. This is illustrated in Figure 1.

• Entities: An entity represents a person, place, organization, or thing (syringe, antigen, vaccine, etc.). Entities can be related to one another via an entity relationship such as place belonging to an organization or series of materials belonging to a vaccination kit.

• Roles: Roles represent a type of part an entity plays. For example, a Person entity may play the role of a provider or a patient.

• Participations: Participations are the link between an act and an entity via a role. A participation is used to describe how an entity participates in the carrying out of an act.

In this context we can represent many different clinical scenarios. In order to make conceptualizing data elements in the SanteDB persistence store easier, much data documentation leverages an information model cards as illustrated in Figure 2.

Templates

SanteDB Acts and Entities can be templated to ease the creation and reuse of common structures. A template is a particular set of rules and pre-set data elements which are used to perform some use case with the underlying base type.

For example, weight and height are two separate types of a QuantityObservation. By creating a “weight” and “height” template, we allow any business processes or user interface elements to understand the rules for a particular entity. It allows software to understand “what kind” of element it is looking at without having to guess based on type/class/mood/determiner/etc.

This test ensures that the recipient of the query can perform a query by the patient’s mother’s identifier.

References

Pre-Conditions / Setup

Setup the receiver such that OID 2.16.840.1.113883.3.72.5.9.1 has assigning authority of TEST which can be assigned from TEST_HARNESS

Ensure that the following patient is registered in the receiver (can be done with the ADT message provided). Name: Jennifer Jones, id: RJ-439^^^TEST, gender: F, dob: 1984-01-25

Ensure that the following patient is registered in the receiver (can be done with the ADT message provided).RJ-440^^^TEST, gender: M, DOB: 2014-10-01

Test Step 1:

Test harness sends a query with mother’s identifier components specified.

Expected Behaviour

• Receiver responds with an AA

• Receiver sends exactly one PID segment with identifier RJ-440 in domain TEST in PID-3

Test Step 2:

Test harness verifies the infant record was created in the receiver.

Expected Behaviour

• Receiver responds with an AA

• Receiver sends exactly one PID segment with identifier RJ-440 in domain TEST in PID-3

An entity within the SanteDB data model is used to represent a person, place, or thing. Entities represent the who, which and where aspects of an action. Entities are further classified into several sub classes illustrated in Figure 1.

Architecturally, SanteDB's data architecture is based around the RIM. SanteDB has a conceptual information model which is implemented in 3 different ways:

• Message Models - The representation of the SanteDB Conceptual Information Model as JSON or XML objects which appear on the wire or when using functions from third party technologies like JavaScript. Message models in SanteDB include:

  • RIM-based XML model (1:1 with conceptual model)

Figure 2 represents a sample information model of a kit of BCG vaccine. The model illustrates how a single tuples in the SanteDB model are related to one another to represent a kit. The material “BCG Vaccine” is comprised of one dose of “BCG Antigen”, one “Syringe”, and one dose of “BCG Diluent”. A box of “BCG Vaccine” represents 25 single doses of “BCG Vaccine” (meaning 25 syringes, 25 antigen and 25 diluent). Finally, from this we can order (via instantiation or inheriting a kind) a kit of GSK 5ml BCG vaccine. This derivation will have the same rules applied (in that this vaccine must have a syringe, antigen, and diluent.

Figure 3 represents a complex scenario of kitting a vaccine and then deriving a specific type of kit. The relationship between the instantiation and the generic concepts of the material would have a type of “Manufactured” meaning the “GSK 5 ml BCG” is a manufactured representation of the generic BCGvaccine.

The SanteDB model also supports more simplistic representation of a “BCG Vaccine” if kits are not required by the jurisdiction that is implementing SanteDB. Figure 4 illustrates a valid representation of BCG in a jurisdiction where only the antigen is tracked.

• • Use Cases understood and documented

  • Requirements documented ("what is success?")

This test validates that the Client Registry rejects a poorly formed message lacking appropriate assigner information in PID-3.

Pre-Conditions / Setup

Prior to executing this test, SanteMPI instances should configure:

• The TEST_OTHER

This test ensures that the receiver is able to store and usefully convey (regurgitate) a more complete patient record having multiple names, addresses, telephone numbers, mother’s identifier, mother’s name, birth date, multiple birth order, etc.

References

This test ensures that the receiver rejects messages which contain identifiers assigned from authorities which are unknown.

Discussion

It is expected that a patient identity cross reference manager will ensure that data is valid prior to recording patient registrations and performing cross reference functions.

The lack of configuration for an identity domain being received by an identity source indicates a misconfiguration of the MPI and/or the identity source. This test ensures that configuration is consistent within a jurisdiction.

This test ensures that the recipient supports the semantics of date matching and approximate matches by date range. This test case will query for an exact date of birth as provided in an admit message, and a fuzzy date of birth (year, and year/month).

References

This test ensures that the receiver is able to match an incoming patient with their mother via the “Mother’s Identifier” property. In this test, the harness with register a patient (the mother) and subsequently will register an infant record (only dob, gender and id) with the mother’s identifier attached. The test will ensure that the link occurred by validating a demographic query contains the mother’s name.

References

A Privacy Impact Assessment (PIA) is a risk management process that helps institutions ensure they meet regulatory requirements and identify the risks and potential impacts their programs and activities will have on an individuals’ privacy.

Conducting a PIA is a means of helping to ensure compliance with any legal requirements set out in jurisdictional legislation, and the requirements of any organizational policies and directives. Adhering to the requirements will reduce the risk of improper or unauthorized collection, use, disclosure, retention or disposal of personal information.

While programs and activities must comply with legal and policy requirements, they should also be designed to incorporate best practices and to minimize negative impacts on the privacy of individuals. For example, you should work to reduce the risk that an individual may suffer harm, such as identity theft, reputational damage, physical harm or distress, as a result of your program’s handling of their personal information. A PIA may not eliminate such risks altogether, but should help to identify and manage them.

PIAs allow institutions to identify and mitigate risks as early and as completely as possible. They are a key tool for decision-makers, enabling them to deal with issues internally and proactively rather than waiting for complaints, external intervention or bad press.

Each jurisdiction will have a unique privacy landscape and may have specific requirements for PIAs, but we have provided a sample PIA guide and template here that should at least help to start the privacy conversation in your project.

Acts are classified into one of these four types based upon their ClassConcept code. This dictates what type of Act the particular tuple in the database represents.

The class concept list is extensible.

The primary duty of a centralized CDR (and more specifically an MPI) is to maintain records from various sources of information. Identity of that information (patient identity, place identity, event identity, etc.) within a health enterprise (a hospital, province or state, country, etc.) is of paramount importance.

Furthermore, the governing of those identities should also be considered. For example:

• Your Immunization System shouldn't be the source of truth for LTC programme identifiers (correct issuing authority)

• You may not want to disclose mental health identifiers to a community outreach application (correct disclosure)

• You don't want facility associated identifiers being mistakenly assigned to patients (correct usage)

Surveying Identity

It is important in any SanteDB deployment (especially for SanteMPI) to perform a survey of identifiers which are used in the context in which the solution will be deployed.

Implementers should note:

• The types of medical and non-medical identifiers which are currently in use.

• Which organizations are responsible for the maintenance and issuing of the identifier.

• The lifecycle of the identifier (i.e. how is a new identifier issued, are the holders authenticated, etc.)

• The format and requirements of the identifier (are there check digits, if so what are they?)

Operationalizing Identity Domains

SanteDB (and by extension SanteMPI) supports a variety of standards, each of which use different labels to identify an identity domain. For example, in FHIR an identity may appear as:

Whereas that same identifier in an HL7v2 message would appear as:

Or in HL7v3 the identifier may appear as:

To properly ensure cross referencing between each of these interfaces, SanteDB will need to know the URL (used primarily in FHIR), the namespce ID (used primarily in HL7v2) and the OID/Universal ID (used primarily in HL7v3).

Since these all need to be unique, it is a good practice that your scheme for these values encompass the entity which owns the identifier, the programme area or department, and the system. For example, if the Ministry of Health runs an infectious disease programme in which an HIV EMR is used, a good Namespace ID for the MRN form that system may be: MOH_ID_HIV_EMR_MRN

Resources

An identity domain worksheet has been created and shared below. This worksheet contains instructions and example data which should assist implementers in the organization of their identity domain planning work.

To use the spreadsheet:

1. Enumerate the issuing organizations in the implementation context (organizations, ministries, etc.) and complete the Issuing Authority sheet.

2. Enumerate each of the identification domains which are used in the context to which SanteDB or SanteMPI will be deployed.

3. Update the cover sheet of your worksheet with relevant metadata about the sheet.

SanteDB's concept dictionary is based heavily on the work done in OpenMRS' Concept Dictionary, the SanteDB concept dictionary is logically made up of four fundamental concepts, described in this page.

Concepts

In SanteDB, a "concept" is a logical construct for representing the idea of something. Concepts are used within the SanteDB core models to represent these ideas on particular attributes. Examples of concepts may be:

• The concept of a "Male", or "Female"

• The concept of a "Syringe" (an object used to inject a substance)

• The concept of "Oral Polio Vaccine" (an antigen administered orally which protects against polio)

Concepts are assigned a unique mnemonic (a human readable term) and a UUID. Additionally concepts may carry one or more display names.

Concept Relationships

Concepts can be related to one another via a relationship. The relationship of one concept to another is used to indicate parent/child relationships, specification/generalization, etc. A relationship applies to two concepts and carries a concept relationship classification which can be one of:

Concept Sets

Concept sets represent a logical grouping of multiple concepts into a single list of related ideas. Concept sets are useful for driving user interface inputs, or allowing the searching/selection of ideas.

For example, a deployment may use the AdministrativeGender concept set to drive their inputs for selecting gender. Jurisdictions can customize those concepts which are members of this set based on their business requirements.

Reference Terms

Reference terms are used for the expression of concept within an external codification system. Reference terms are used to translate concept sets into wire-level codifications of those concepts. This design allows the SanteDB internal data model to maintain integrity with a known internal series of concepts, while mapping those concepts to external code systems which may or may not be subjected to changes (for example: ICD9, ICD10 and ICD11 can be implemented by simply mapping).

This page provides a summary of the SanteDB architecture. A more detailed description of this architecture can be found in the SanteDB Functional Design Specification (http://santesuite.org/assets/uploads/sdb-arch-1.11.pdf)

Overall Architecture

A general overview and introduction to SanteDB is provided here.

SanteDB is a comprised of several software components which operate together to form the basis of a cohesive digital health infrastructure.

iCDR Server

The iCDR server is the central integrated clinical data repository which is used to coordinate the many connected clients in an implementation. Typically an implementation of SanteDB will only ever have one logical iCDR instance (i.e. many physical servers are often deployed for scalability however the logical grouping of iCDR servers is acting as a single iCDR).

The primary responsibilities of the iCDR are:

• Maintain a master dataset for the entire deployment of SanteDB in a particular health role.

• Facilitate the synchronization and sharing of data between sites within the deployment.

• Integrate with upstream services such as audit repositories, client registries, etc.

• Distribute "over the air" (OTA) software updates to connected clients and apps

dCDR Clients

The dCDR clients are the disconnected clients which connect to the central iCDR and are typically embedded in applications used by clinics or mobile applications used by end users. The term dCDR client is used loosely to describe any client which is implemented on the dCDR technology. dCDR clients are deployed in data centers, in clinics, on tablets, etc. A deployment of SanteDB will have multiple, potentially hundreds or thousands of, dCDR clients.

No matter the implementation, the dCDR clients are primarily responsible for:

• Providing offline access to relevant subsets of data synchronized and replicated from the central iCDR server

• Caching centralized credentials, and providing local clinic-level authentication

• Serving out the user interface, reports, and other end-user facing elements

• Providing a federation point for other dCDR instances

dCDR Android Application

The dCDR Android Application is an implementation of the dCDR services on the Google Android operating system. The dCDR Android application is used whenever tablet or phone users will require access to the SanteDB infrastructure while operating on poor/slow/unavailable cellular internet connections.

The dCDR Android application only exposes the user interface services, offline gateway services such as FHIR, HL7v2, and ATNA are disabled, as is off-host UI access. When the Android host process launches the dCDR service core, it generates a unique secret for that application run, and expects this in the SDB-Magic header on all requests.

dCDR Windows / Linux Applications

The dCDR Windows and Linux applications are self-contained applications which run the SanteDB user interface, and provide a known web-browser component to render them. Like the Android client, these desktop applications disable all API access and generate unique key which is shared between the web-view control and the dCDR services, and is required to access those services.

dCDR Gateway

The dCDR Gateway is a network service which implements the dCDR functionality and is intended for use in environments where third party applications (or users in a shared local network) require access to offline functionality.

The dCDR Gateway exposes FHIR, HL7v2, ATNA, and API calls to any connected client on a local network. The Gateway provides the services of a SanteDB iCDR instance, where clients connected on the local network have no knowledge of the overall connectivity of the clinic or environment they're operating within. This allows applications to continue to operate in local clinic environments even when connectivity to the iCDR is not available.

dCDR Web Portal

The dCDR Web Portal is a specialized dCDR environment which has no offline capability. It is primarily designed to operate as a daemon and to serve out, on the internet, the user interfaces directly connected to the central iCDR. This is the technology used to host the administrative panels, any shared/central infrastructure, etc.

Topics

This test will ensure that the client registry appropriately handles a merge condition whereby the local authority has not assigning authority to perform or merge the identifiers provided. This test will also ensure that merges across assigning authorities cannot be performed

References

Pre-Conditions / Setup

Setup the receiver so that OID 2.16.840.1.113883.3.72.5.9.2 has assigning authority of TEST_A which can be assigned from TEST_HARNESS_A

Setup the receiver so that OID 2.16.840.1.113883.3.72.5.9.3 has assigning authority of TEST_B which can be assigned from TEST_HARNESS_B

Ensure that the following patient is registered in the receiver (can be done with the ADT message provided). Name: Sam Smith, id: RJ-203^^^TEST_A, gender: F, dob: 1989-02-25

Ensure that the following patient is registered in the receiver (can be done with the ADT message provided). Name: Samantha Smith, id: RJ-292^^^TEST_A, gender: F, dob: 1989-02

Ensure that the following patient is registered in the receiver (can be done with the ADT message provided). Name: Samantha Smith, id: SJ-204^^^TEST_B, gender: F, dob: 1989-02

Test Step 1:

Test harness (as TEST_HARNESS_B) sends ADT^A40 message attempting to merge identities from TEST_A domain.

Expected Behaviour

• Receiver rejects message with an AE

• MSH-5 and MSH-6 matches “TEST_HARNESS_B|TEST”

• An ERR segment exists identifying the error

Test Step 2:

Test harness (as TEST_HARNESS_B) sends ADT^A40 message attempting to merge across domains by instructing the receiver to merge an identifier from TEST_A into TEST_B.

Expected Behaviour

• Receiver rejects message with an AE or AR

• MSH-5 and MSH-6 matches “TEST_HARNESS_B|TEST”

• An ERR segment exists identifying the error

Test Step 3:

Test harness (as TEST_HARNESS_B) sends ADT^A40 message attempting to merge a patient identifier which does not exist.

Expected Behaviour

• Receiver rejects message with an AE or AR

• MSH-5 and MSH-6 matches “TEST_HARNESS_B|TEST”

• An ERR segment exists identifying the error with HL7 code of 204 (key does not exist)

This test case ensures that the recipient of the query can perform a patient demographics query based on the PID-3 values provided in an admit message.

References

Pre-Conditions / Setup

Setup the receiver so that OID 2.16.840.1.113883.3.72.5.9.1 has assigning authority of TEST

Setup the receiver so that OID 2.16.840.1.113883.3.72.5.9.9 has assigning authority of NID

Ensure that the following patient is registered in the receiver (can be done with the ADT message provided). Name: Jennifer Jones, id: RJ-439^^^TEST, gender: F, dob: 1984-01-25

Test Step 1:

Test harness sends a PDQ message containing a patient identifier which is known to the receiver:

Expected Behaviour

• Receiver Accepts Message with an AA

• QAK segment contains OK

• Response contains a PID segment containing:

  • PID-3=439^^^TEST

Test Step 2:

Test harness sends a PDQ message containing a patient identifier which is unknown to the receiver:

Expected Behaviour

• Receiver accepts the message with AA

• QAK segment contains NF

• Response contains no PID segments

Test Step 3:

Test harness sends a PDQ message with an invalid query parameter of @PID.3.4.99

Expected Behaviour

• Receiver rejects the message with AR or AE

• QAK segment contains AE

• Response contains no PID segments

Test Step 4:

Test harness sends a PDQ message and specifies what domains should be returned in the QPD-8 containing a valid domain of TEST

Expected Behaviour

• Receiver accepts message with an AA

• QAK segment contains OK

• Response contains exactly one PID segment

  • PID-3 (Exactly one)=439^^^TEST

Test Step 5:

Test harness sends a PDQ message and specifies what domains should be returned in QPD-8 with a valid domain of NID which has no matching identifiers.

Expected Behaviour

• Receiver accepts message with an AA

• QAK segment contains NF

• No PID segments are returned in the response

Test Step 6:

Test harness sends a PDQ message and specifies what domains should be returned in QPD-8 with an invalid domain of RANDOM.

Expected Behaviour

• Receiver rejects the message with AE

• Receiver indicates query error with QAK of AE

• No PID segments are returned

• Receiver indicates QPD^1^8 in the ERR segment

Entities are further classified by their class code and determiner code. The determiner code of an entity is responsible from differentiating a type of an entity (i.e. antigen, dose number, material type, etc.) and an instance or series of instances of an entity (an actual vial of vaccine, a box of syringes, etc.). Most entities within the SanteDB system are expected to be stored as instances of entities, classes of entities will primarily be restricted to materials whereby a class of antigens (OPV for example) will have both instances (vials of OPV) and sub-classes of representing dose numbers (OPV0 – OPV3). Provides a summary of the entity classes and how they are classified in the data model.

This test ensures that the recipient of the query can perform a query on a series of demographics fields. The test harness will perform a query on a series of combinations of parameters such as name + gender, name + date of birth, gender + date of birth.

References

Pre-Conditions / Setup

Setup the receiver such that OID 2.16.840.1.113883.3.72.5.9.1 has assigning authority of TEST which can be assigned from TEST_HARNESS

Ensure that the following patient is registered in the receiver (can be done with the ADT message provided). Name: Jennifer Jones, id: RJ-439^^^TEST, gender: F, dob: 1984-01-25

Test Step 1:

Test harness sends a query with patient’s name and gender which results in a match.

Expected Behaviour

• Receiver responds with an AA

• Receiver indicates records found with QAK of OK

• Receiver sends exactly one PID segment with identifier RJ-439 in domain TEST in PID-3

Test Step 2:

Test harness sends a query with fuzzy date of birth and patient’s name which results in a match.

Expected Behaviour

• Receiver responds with an AA

• Receiver indicates records found with QAK of OK

• Receiver sends exactly one PID segment with identifier RJ-439 in domain TEST in PID-3

Test Step 3:

Test harness sends a query with date of birth precise to the day in which a gender which results in a match.

Expected Behaviour

• Receiver responds with an AA

• Receiver indicates records found with QAK of OK

• Receiver sends exactly one PID segment with identifier RJ-439 in domain TEST in PID-3

Test Step 4:

Test harness sends a query with patient’s name and gender which results in no match.

Expected Behaviour

• Receiver responds with an AA

• Receiver indicates no records found with QAK of NF

• Receiver sends no PID segments

Test Step 5:

Test harness sends a query with fuzzy date of birth and patient’s name which results in no match.

Expected Behaviour

• Receiver responds with an AA

• Receiver indicates no records found with QAK of NF

• Receiver sends no PID segments

After installing a SanteDB iCDR product, such as SanteMPI or SanteIMS, there is often a need to validate that the software is setup and functioning correctly. This page provides reference materials for running these installation qualification tests.

User Interface Testing

The Security Administration Testing wiki article provides test steps that users can perform to validate that the security environment of SanteDB is running correctly.

If you're running the iCDR and the web host portal you can use the User Interface Test Cases , if you're operating SanteDB iCDR in a headless environment the Admin Console tests provide equivalent tests using the sdbac tooling.

SanteMPI Functional Testing

If you've installed the SanteMPI solution you can use the test cases to validate your configuration of SanteMPI.

The test cases cover:

Security Environment Qualification

It is recommended that, after is performed that a complete network scan be performed to ensure that the attack surface area of the environment is minimal.

• Perform a security scan of the applications involved (see: ) to ensure SSL, XSS, CORS, and other web security practices have been configured appropriately

  • Add any blocking scripts to browser headers your Application Firewall may be adding

  • Ensure proper caching policies and login policies are in place

• Perform a network port scan/attach tool to ensure that opened ports and services are minimal (see: )

  • Ensure that only ports you want opened are open

  • Ensure that ports that are open are secured.

• Use OpenSSL to validate that your SSL certificates are properly configured

The Conceptual Concept Dictionary expressed in the physical data model in ADO.NET providers is illustrated below.

You can quickly add test/sample data by copying dataset files into the /santedb/data directory of the docker container either using a custom dockerfile or by mounting a volume from the docker image.

Dataset Files

These dataset files can be generated from the sdbac command prompt with the cdr.query command to produce dataset files. Dataset files provide a 1:1 mapping to the underlying CDR storage engine and are expressed in XML RIM objects. Dataset files can include:

• Infrastructure elements like Assigning Authorities, Concepts, Extension Types, etc.

• Clinical elements like Entities or Acts

For example, to initialize an MPI with an identity domain, and an organization with a custom policy, for a particular use case, create a new dataset file containing the identity domain, organization and custom policy:

The file would be copied into the /santedb/data directory of the santedb-mpi or santedb-icdr container with the following Dockerfile.

FHIR Resources

You can also seed data into the /santedb/data/fhir directory of the container using a custom dockerfile or by mounting the volume from the docker container.

FHIR resources are limited to only those resources which have a IFhirResourceHandler implementation registered and configured. (TODO: Insert link)

FHIR resources can be in JSON or in XML format, and are simply placed in the directory. The seeder then processes these files on application start and will generate two files:

• A file with a .completed extension which indicates that the message contents were successfully processed and included into the SanteDB iCDR database.

• A file with a .response extension which is the FHIR response that would have been sent via the REST API. This is useful for diagnosing issues with your FHIR message being seeded.

Deploying on Container

You can deploy either dataset files or FHIR files onto your running iCDR container by either including the files in a custom Dockerfile such as:

Alternately , you can mount the /santedb/data directory as a volume for your container and copy the files, or you can use a command line interface and docker cp such as:

Pull santempi:

Pull santempi repository from github : https://github.com/santedb/santempi.git

Install docker containers:

Having docker installed, run the following command inside santempi/instant directory where the docker-compose.yml file exists to spin up docker containers.

Get sdbac(santedb admin console) from latest release

Get the latest sdbac release from github:

Download the sdbac.zip and extract the files.

Configure santempi instances for pre-conditions setup

1-Run the following commands inside sdbac directory where the sdbac.exe is located or run the sdbac.exe directly.

2-Insert the credentials for Username and Password.

3-Wait for the system to get ready

4-Run the following commands:

To create TEST_HARNESS application run:

To create TEST_HARNESS|TEST device run:

To create TEST identity domain and set the assigned authority to TEST_HARNESS run:

Pull hl7-testing-tool:

Pull hl7-testing-tool from github:

Run hl7-testing-tool:

Run hl7-testing-tool solution with visual studio.

They can be run as an entire test suite or an individual test case or test step.

For a test step to pass all mandatory assertions and at least one of alternate assertions for the same terserstring must pass.

SanteDB 1.x was a near direct refactor of the original OpenIZ core, which had components from the MEDIC Service Core project dating back to 2008/2009. While SanteDB 2.x was a refactor off this .NET Framework and PCL code to .NET Standard, there are still many components and patterns (ghosts) of the original service core code from 2008.

The SanteDB Version 3.x roadmap seeks to fully remove these patterns and re-implement many of the core services. However, this presents a problem in that it makes incremental change difficult, and will break the services. For this reason, much of the Version 3.x roadmap is currently in the design / wishlist phase.

Refactor Persistence Layer (done)

Once a docker image is setup - it can now be seeded or populated with data. In addition to running the installation qualification tool, you can seed the ONC dataset into the SanteMPI server which has just been setup.

Download Resources

This test ensures that the recipient of the query can perform an exact match on a patient’s name as provided in an admit message. The test will additionally test partial matching using phonetics and patterns. The recipient must pass one of the phonetic or pattern matching cases.

References

SanteDB's components can be used to enable basic data privacy controls on data stored within the SanteDB solution. SanteDB allows objects such as Entities, Acts and identifiers to be tagged with one or more policies which apply to that particular object.

Privacy Enforcement Service

Whenever an Entity, Act or Assigning Authority (identity domain) is tagged with an access policy (such as provided in the ) the configured Privacy Enforcement Service is called and validate access to the record and to apply any actions to the outgoing (or incoming) data.

This test will ensure that the client registry can appropriately handle a merge condition whereby a local assigning authority notifies the client registry of a local merge (two local identifiers are in fact the same person).

References

SanteDB provides a number of virtual appliances to assist in the rapid deployment of service environments using Open Virtualization Appliance (OVA) files.

Virtual Appliance Types

Headless Server Environment

This test ensures that the receiver does not reject a message containing only an identifier, and one of gender, date of birth, mother’s identifier. This test makes no assertion about merging/matching patients

Discussion

This test mimics the environment whereby a newborn demographic with minimal patient information (gender and date of birth) can be stored by the client registry and faithfully returned with an appropriate query to the interface.

This test validates the MPI/CR's ability to link a mother's record with a newborn's record, and to query that data back from the MPI. This option uses the Pediatrics Demographics Option in section 8.2.1 of the

There are a variety of ways in which SanteDB can be deployed within your architecture. You can use any of the SanteDB technologies to fill any one of a number of logical roles within your broader e-health strategy.

This page discusses the ways in which SanteDB can be operationalized. It is important to note that these patterns can be mixed, as they leverage common user interface and messaging frameworks.

Online Only Patterns