Configuring Privacy Controls

This article documents and uses features of SanteDB 3.0. The implementation of these features on previous versions of SanteDB may be partial and/or missing.

All SanteDB solutions (SanteMPI, SanteEMR, and SanteIMS) are designed to support adherence to a variety of privacy controls which can be used by implementers to conform to local privacy legislation such as:

Because SanteDB provides a platform for implementation of many different use cases in many different legislative environments, it is the responsibility of implementers to properly configure the necessary controls in the SanteDB product to match their use case. This article provides brief guidance on how such configurations are made to the underlying privacy control system using legislatively agnostic terminology.

Accountability

When deploying SanteDB and its related software, be sure to appoint a member on your team (or establish a team) which is accountable for assessing the compliance of your SanteDB implementation with the local privacy legislation. Specifically:

  • Develop and Document Personal Information Policies and Practices

  • Develop a Privacy Management Programme/Procedures

  • Complete a Privacy Impact Assessment and identify:

    • What information is required to be collected?

    • How is the information to be collected?

    • What is the information used for?

    • How is the information secured?

    • Which users have access to the information?

    • What third parties is the information shared with?

    • What are the policies/timelines for retaining and disposing of the information?

  • Develop and document procedures for:

    • Informing Patients, Providers and other stakeholders of the use of their personal data.

    • Obtaining informed consent of the individuals whose data is used and stored in SanteDB

    • Ensuring that information collected is current and up to date.

    • Investigating breaches, fielding requests for investigations, inquiries requests for obtaining access to private information (from authorities, patients, etc.)

    • Training employees and staff members on the privacy procedures and policies being implemented.

All of these assets should be made publicly available to patients, providers and staff members who will interact with your deployment of SanteDB.

Identify Purpose, Limiting Collection, Disclosure and Retention of Data

SanteDB is a generic CDR which can store an almost infinite number of data fields related to Patients, Providers, Locations, Staff Members, etc. However, not all of this data is used for every context. For example, using SanteIMS as an EIR will have different uses and needs for collecting data than SanteMPI as a national patient index.

Implementing a limitation on the collection of data in SanteDB begins with reviewing the data requirements of your project and reviewing the SanteDB Conceptual Information Architecture. After determining the necessary fields, you should decide:

  • Do we need to collect this information for internal use? (for example, matching or notifications)

  • If we collect this data, what do we need to do to safeguard it? (for example, encrypting it or restricting disclosure)

  • If we collect this data, how long does it remain active?

Limiting Data Collection

For information in the conceptual information model which will not be used, the SanteDB configuration needs to be updated to restrict the use of the fields in question. This is done by editing the santedb.config.xml file on the iCDR server using either the Configuration Tool, or editing the file directly.

The App Settings is used to change the behavior of data which is collected. These settings will:

  • Reject any message which contains the restricted data fields listed regardless of where/how the data originated into the CDR (FHIR, HL7, etc.)

  • Hide any inputs on the user interface which are used to collect this information

The Action column describes what this setting does when set to TRUE in the configuration:

  • Forbid -> The data field is permitted and stored by default, when the setting is enabled, the information is forbidden:

    • Requests to register or update the data result in a rejection of the message

    • User interface elements to collect the data disappear

  • Allow -> The data field is forbidden by default, when the setting is enabled, the information is allowed:

    • Requests to register or update the data will not result in a rejection message

    • User interface elements to collect the data will appear.

SettingData FieldAction

forbid.patient.name.family

Patient Family Names

Forbid

forbid.patient.name.given

Patient Given Names

Forbid

forbid.patient.name.prefix

Patient Name Prefixes (Mr, Mrs, etc.)

Forbid

forbid.patient.name.suffix

Patient Name Suffixies (Jr, Sr, etc.)

Forbid

forbid.patient.address.state

Patient Addresses with State information

Forbid

forbid.patient.address.county

Patient Addresses with County information

Forbid

forbid.patient.address.city

Patient Addresses with City information

Forbid

forbid.patient.address.precinct

Patient Addresses with Precinct information

Forbid

forbid.patient.address.street

Patient Addresses with Street information

Forbid

forbid.patient.address.postalcode

Patient Addresses with PostalCode information

Forbid

allow.patient.religion

Patient Religious Affiliation

Allow

allow.patient.ethnicity

Patient Ethnic Group

Allow

allow.patient.livingArrangement

Patient Living Arrangement (Alone, Ward of State, Orphan, etc.)

Allow

allow.patient.maritalStatus

Patient Marital Status (Single, Married, Divorced, etc.)

Allow

allow.patient.educationLevel

Patient Education Level

Allow

forbid.person.occupation

Patient, Provider, or Relative's Occupation

Forbid

forbid.person.gender

Patient, Provider or Relative's Administrative Gender

Forbid

forbid.person.vipStatus

Patient, Provider or Relative's VIP status

Forbid

forbid.person.nationality

Patient, Provider or Relatives Nationality

Forbid

Propagation to dCDR Instances

The settings listed above can be propagated to dCDR instances by populating the <publicSettings> element in the AmiConfigurationSection:

<section xsi:type="AmiConfigurationSection">
    <welcomeMessage>Welcome to SanteMPI</welcomeMessage>
    <publicSettings>    
      <add key="allow.patient.maritalStatus" value="true" />

This can also be set using the Configuration Tool by navigating to Messaging > Administrative Management Interface

In Configuration Tool

To configure these settings in the configuration tool, navigate to the Settings Editor tab and select ApplicationServiceContextConfigurationSection and expand App Settings.

Then, enter each setting as a new entry and set the value to true or false as illustrated.

Configuration File

The information can be updated in the configuration file in the <section xsi:type="ApplicationServiceContextConfigurationSeciton"> element:

<section xsi:type="ApplicationServiceContextConfigurationSection" 
    allowUnsignedAssemblies="true" threadPoolSize="4">
  <serviceProviders>
    <!-- Service Provider Lines -->
  </serviceProviders>
  <appSettings>
    <add key="allow.patient.martialStatus" value="true" />
    <add key="allow.patient.ethnicity" value="false" />
    <add key="allow.patient.educationLevel" value="true" />
    <add key="allow.patient.livingArrangement" value="true" />
    <add key="allow.patient.religion" value="true" />
  </appSettings>
</section>

Limiting Concept Sets

Another method of limiting the data collection is the restriction of individual codified fields. For example, a deployment may wish to allow the collection of a person's occupation (the default setting, or forbid.person.occupation=false) but restrict the collection to two categories used for eligibility determination. To do this, the Concept Set Editor can be used to edit the members of the concept set to only those required in the deployment. The concept set bindings for the data fields above are as follows:

FieldConcept Set

Patient Marital Status

MaritalStatus

Patient Religious Affiliation

Religion

Patient Living Arrangement

LivingArrangement

Patient Education Level

EducationLevel

Patient Ethnicity

Ethnicity

Person Occupation

OccupationType

Person Administrative Gender

AdministrativeGenderCode

Person VIP Status

VeryImportantPersonStatus

Limiting Data Disclosure

As documented in the SanteDB Privacy Architecture article, SanteDB can limit the disclosure of data from the CDR to clients who lack the appropriate policies. Configuring this privacy guard involves the following steps:

Auditing Data Disclosure

Administrators are encouraged to ensure that the Audit and Accountability subsystem of their iCDR and dCDR are appropriate configured for their use case. This is done via the Configuration Tool in the Audit and Accountability section.

Administrators should ensure that the appropriate data actions are being persisted and/or (if required) shipped to a central audit repository for review by privacy officers.

Once configured, privacy officers can use the SanteDB administration panel to review these audits.

Reviewing Audits

Limiting Data Retention

Limitation of the retention of data (including audits, and any CDR clinical data) is handled by the Data Archiving Service and ensuring that the Data Retention Job is enabled and scheduled. Generally, this process involves:

  • Determine the appropriate retention parameters which are required such as cutoff dates for archiving or purging the data, lookups, etc.

  • Determine the types of data to which the retention policies apply (Patients, Observations, etc.) and configuring the appropriate retention strategies.

  • Enabling the retention job and setting the schedule for retention.

These settings are documented in the configuration tool's Data Retention Service Configuration.

Safeguarding Personal Information

SanteDB provides a variety of methods for securing personal information while it is being transmitted to third parties, and while it is stored on the file system. There are several articles which explain the configuration of these options:

Securing SanteDB ConfigurationSecuring SanteDB DatabasesSecuring SanteDB APIs

These safeguards should be enabled prior to the deployment and operationalization of your SanteDB deployment to ensure that your local legislative requirements are adhered to.

Ensuring Data Accuracy

Decisions and information which are made on out of date, or inaccurate data can adversely impact patient safety, as well as the protection of their data. It is therefore important that appropriate procedures are put in place to ensure that data is accurate and conflicting/old data is not actioned upon.

The following non-technical procedures should be considered when operationalizing your SanteDB software:

  • Ensure that staff members and providers are trained to regularly update Patient profile information at the start of each visit.

  • Ensure that patient's are authenticated using some of reliable method (government issued photo ID, storing a photograph of the patient, biometric extensions, etc.)

  • Ensure that staff, and business rules are configured to review the data quality/detected issues prior to making decisions (see: Data Quality Services)

SanteDB provides a limited function for tagging and/or rejecting data which is incomplete or does not adhere to certain data quality markers.

Data Quality ServicesData Quality TabData Quality Rules

Individual Access

It is important that individuals (Patients, Providers, etc.) can challenge a data custodian to enumerate the data which the CDR holds about them, and to understand who has observed and/or interacted with this information. In SanteDB this is addressed via:

SanteDB does not provide a direct method of purging data from within the user interface directly. Administrators can configure data retention rules which archive and subsequently purge data based on tags they configure in their own deployment applets.

Last updated