Smile CDR v2022.11.PRE
On this page:

11.5MDM Examples


This page contains example interceptors that can be registered with MDM.

11.5.1Example: Operate on resources analyzed by MDM, before and after analysis


The following interceptor is intended to be used with MDM module, and can be used to operate on resources analyzed by MDM.

The sample interceptor has two goals, when MDM module is called to analyze input Patient resources:

  • The first goal is to make sure Patient resources have US SSN identifier, before MDM analysis
  • The second goal is to create/update a Person resource on an external FHIR repository, after MDM analysis

In the sample interceptor, before passing the input Patient resource to MDM module, using Pointcut.MDM_BEFORE_PERSISTED_RESOURCE_CHECKED, it creates a Task resource for input Patient resource that is missing a US SSN value in its identifiers, making it easier to update these Patient resources later with an appropriate and trackable workflow.

Once a Patient resource has been processed by the MDM module, the interceptor will be invoked using Pointcut.MDM_AFTER_PERSISTED_RESOURCE_CHECKED method. The interceptor then verifies if the input Patient resource was newly created, verifies the MDM links to create or update a Person resource based on the linked Patient golden resource information, and finally sends the Person resource to an external FHIR repository.

The sample interceptor also demonstrates how to use Spring Configuration class and DaoRegistry to access data.

 * This sample interceptor is intended to be used with MDM module.
 * MDM module configuration 'Interceptor Bean Types' should be set to 'com.smilecdr.demo.server.r4.TestServerAppCtx'
 * to test it in Smile CDR, so appropriate dependencies could be passed to its constructor.
 * <p>
 * The sample interceptor has two goals, when operating on Patient resources.
 * </p><p>
 * The first goal is to make sure Patient resources have US SSN identifier,
 * which is treated as an important value in our sample scenario,
 * before the MDM module searches for candidate Patient resources and tries to create links.
 * If the operated Patient resource is missing a US SSN identifier,
 * the interceptor will then create a Task resource in the internal FHIR repository to facilitate tracking
 * these Patient resources that need to be updated.
 * </p><p>
 * The second goal is to create a Person resource on an external FHIR repository,
 * based on the golden Patient resource, for newly created Patient resources,
 * once the MDM module linked the created Patient resources to a golden Patient resource.
 * </p>
public class PatientMDMInterceptor {

	// let's add some entries in smile.log!
	private static final Logger ourLog = LoggerFactory.getLogger(PatientMDMInterceptor.class);

	private final static String IDENTIFIER_US_SSN_SYSTEM = "";

	// used to access internal / local FHIR repository
	private final IGenericClient myInternalFhirClient;

	// used to access a potential external / remote FHIR repository
	private final IGenericClient myExternalFhirClient;

	// used to access local FHIR repository directly with Dao, see important note about it in TestServerAppCtx
	private final DaoRegistry myDaoRegistry;

	private IFhirResourceDao<Patient> myPatientDao;

	private IFhirResourceDao<Task> myTaskDao;

	public PatientMDMInterceptor(
		IGenericClient theInternalFhirClient,
		IGenericClient theExternalFhirClient,
		DaoRegistry theDaoRegistry) {

		myInternalFhirClient = theInternalFhirClient;
		myExternalFhirClient = theExternalFhirClient;
		myDaoRegistry = theDaoRegistry;

	public void init() {
		// we don't need to retrieve the DAO from the registry at each usage, so do it once in a PostConstruct method"Initialize Patient MDM Interceptor");
		myPatientDao = myDaoRegistry.getResourceDao(Patient.class);
		myTaskDao = myDaoRegistry.getResourceDao(Task.class);

	 * Interception method, called before MDM module searches for candidate resources and tries to create links.
	 * @param theResource Operated resource, which MDM will analyze after interception
	public void mdmBeforePersistedResourceChecked(IBaseResource theResource) {

		if (!ResourceType.Patient.toString().equals(theResource.fhirType())) {
			// safeguard, quickly exit if we intercepted MDM call on something other than Patient resource
			// which shouldn't happen if MDM is properly configured
		StopWatch stopWatch = new StopWatch();
		try {
			Patient patient = (Patient) theResource;
			Optional<Identifier> ssnIdentifier = patient.getIdentifier().stream()
				.filter(identifier -> IDENTIFIER_US_SSN_SYSTEM.equals(identifier.getSystem()))
			if (ssnIdentifier.isEmpty()) {
				Task task = buildTaskForPatientWithoutSsn(patient);"Saving\n{}\n",

				DaoMethodOutcome daoMethodOutcome = myTaskDao.create(task);
				// we could have used the internal FhirClient here instead of calling the Dao
				// if we had wanted more standard/robust code
				// myInternalFhirClient
				//	.create()
				//	.resource(task)
				//	.execute();
				if (daoMethodOutcome.getCreated()) {"Task successfully created\n{}\n",
		finally {"Interceptor MDM_BEFORE_PERSISTED_RESOURCE_CHECKED - ended, execution took {}", stopWatch);

	 * Interception method, called after MDM module created links for the operated resource
	 * according to the MDM rule definition provided in MDM module.
	 * @param theResourceOperationMessage The information about the operated resource
	 * @param theTransactionLogMessages The Transaction log messages about the operated resource
	 * @param theMdmLinkEvent The MDM links information, after MDM module analyzed the operated resource
	public void mdmAfterPersistedResourceChecked(
		ResourceOperationMessage theResourceOperationMessage,
		TransactionLogMessages theTransactionLogMessages,
		MdmLinkEvent theMdmLinkEvent) {

		IBaseResource resource = theResourceOperationMessage.getPayload(myInternalFhirClient.getFhirContext());
		if (!ResourceType.Patient.toString().equals(resource.fhirType())) {
			// safeguard, quickly exit if we intercepted MDM call on something other than Patient resource
			// which shouldn't happen if MDM is properly configured
		StopWatch stopWatch = new StopWatch();
		try {
			// verify the operation done on the operated resource,
			// as in this demo, we want to check MDM links for newly created Patient resource only
			if (BaseResourceMessage.OperationTypeEnum.CREATE.equals(theResourceOperationMessage.getOperationType())) {

				for (MdmLinkJson mdmLinkJson : theMdmLinkEvent.getMdmLinks()) {
					String goldenResourceId = mdmLinkJson.getGoldenResourceId();

					if (MdmMatchResultEnum.MATCH.equals(mdmLinkJson.getMatchResult())) {
						// it means the newly created Patient resource is linked to a golden resource
						// as a matching resource, according to the MDM rule definition provided in MDM module
						Patient goldenResource = getGoldenResource(goldenResourceId);
						if (goldenResource != null) {
							// build a unique Person resource based on golden resource information
							Person person = buildPersonFromGoldenResource(goldenResource);"Sending to external FHIR repository\n{}\n",

							// and send that Person resource to our external FHIR repository
							// using PUT {external-base-url}/Person/{person-fhir-id}
							// so this will either update or create the Person resource if not present
					else if (MdmMatchResultEnum.POSSIBLE_MATCH.equals(mdmLinkJson.getMatchResult())) {
						// in this case, we could create a task for someone to settle the possible match
						// using $mdm-update-link operation!"MDM Possible match link for golden resource {}", goldenResourceId);
		finally {"Interceptor MDM_AFTER_PERSISTED_RESOURCE_CHECKED - ended, execution took {}", stopWatch);

	private Task buildTaskForPatientWithoutSsn(Patient thePatient) {

		Reference patientReference = new Reference(thePatient);

		return new Task()
			.setCode(new CodeableConcept().setText("Missing required information"))
			.setDescription("Patient without Social Security Number; patient should be contacted to get that important information");

	private Patient getGoldenResource(String theGoldenResourceId) {

		Patient goldenResource = null;
		try {
			// golden resources are like any other Patient resources
			// but with meta.tag entries and an additional identifier
			// (having '' system)
			// MDM module keeps the golden record updated according to MDM Survivorship Script
			// (usually, with the latest Patient information, but it is configurable)
			goldenResource = IdType(theGoldenResourceId));

			// we could have used the internal FhirClient here instead of calling the Dao
			// if we had wanted more standard/robust code
			// goldenResource = myInternalFhirClient
			//	.read()
			//	.resource(Patient.class)
			//	.withId(goldenResourceId)
			//	.execute();

		} catch (BaseServerResponseException theBaseServerResponseException) {
			ourLog.error("Unable to get golden resource " + theGoldenResourceId,
		return goldenResource;

	private Person buildPersonFromGoldenResource(
		Patient theGoldenResource) {

		// build Person resource from Patient golden record
		// here, for demonstration purposes, we don't want to forward any internal FHIR id
		// to the external FHIR repository
		// so create the same Person FHIR id for the same Patient golden record FHIR id
		// to make sure we don't create multiple Person resources for the same Patient golden record
		// as it is a purposed requirement on the external FHIR repository
		UUID personFhirIdUUID = UUID.nameUUIDFromBytes(

		Person person = new Person();
		// filter out the additional internal identifier
		// (having '' system)
		// from golden record
			.filter(identifier -> MdmConstants.HAPI_ENTERPRISE_IDENTIFIER_SYSTEM.equals(identifier.getSystem()))
		if (theGoldenResource.hasActive()) {
			new Reference()
				// dao_config.allow_external_references.enabled must be enabled
				// 'Allow External References Enabled' in 'Persistence' module
					+ (!myExternalFhirClient.getServerBase().endsWith("/") ? "/" : "")
					+ theGoldenResource.fhirType() + "/" + theGoldenResource.getIdPart())
				.setDisplay("Golden resource reference in source FHIR repository")
			// According to the MDM rule definition, this is the same person
		return person;

MDM module configuration Interceptor Bean Types should be set to com.smilecdr.demo.server.r4.TestServerAppCtx, to test PatientMDMInterceptor.

 * This sample interceptor configuration is intended to be used with MDM module.
 * MDM module configuration 'Interceptor Bean Types' should be set to 'com.smilecdr.demo.server.r4.TestServerAppCtx'
 * to test PatientMDMInterceptor in Smile CDR.
 * <p>
 * Sample MDM module configuration
 * </p><p>
 * A sample 'MDM Rule Definition Script' is provided in resources/patient.mdm.interceptor/sample.mdm.rule.definition.json
 * and 'MDM Survivorship Script' is provided in resources/patient.mdm.interceptor/sample.mdm.survivorship.script.js
 * that could be used to test PatientMDMInterceptor.
 * See <a href="">MDM Quickstart</a>
 * and <a href="">MDM Survivorship rules</a>
 * for more information about MDM configuration.
 * </p>
public class TestServerAppCtx {

	// base url to our local/internal FHIR repository
	private static final String INTERNAL_FHIR_BASE_URL = "http://localhost:8000/";

	// base url to an external FHIR repository
	// it could be another Smile CDR FHIR Endpoint hosted in the cloud, for example,
	// or a second FHIR endpoint configured in the same Smile CDR instance.
	// For the purposes of this demo, and to make it simpler, we will use the same endpoint as our internal one
	// and name it external in the code.
	// The important part is that we will create two distinct FHIR clients.
	private static final String EXTERNAL_FHIR_BASE_URL = "http://localhost:8000/";

	 * Important note about DaoRegistry
	 * <p>
	 * It is not the best practice to use Dao to access data, as they are highly tied to Hapi-FHIR / Smile CDR version.
	 * The interfaces and/or behaviour can change quite a lot between versions,
	 * so there should be no expectation on compatibility between versions used.
	 * It is much safer to use a FHIR client for long term use to retrieve/send data from/to a FHIR repository,
	 * (IGenericClient created from FhirContext.newRestfulGenericClient())
	 * as the interfaces and/or behaviour are more guaranteed by the FHIR specification.
	 * But in some specific cases, a Dao can be used. This example demonstrates how to use the Dao.
	 * Also, using Dao could allow users to access data that might not be permitted normally,
	 * depending on the user permissions. So it needs to be planned carefully.
	 * </p>
	 * Implementation note
	 * <p>
	 * Smile CDR will provide an instance of DaoRegistry via dependency injection,
	 * so it is not required to manually configure it / add it in Spring Context
	 * with @Bean annotation.
	 * </p>
	private DaoRegistry myDaoRegistry;

	@Bean(name = "interceptorFhirContext")
	public FhirContext getFhirContext() {
		return FhirContext.forR4();

	@Bean(name = "internalFhirClient")
	public IGenericClient getInternalFhirClient(
		@Qualifier("interceptorFhirContext") FhirContext theFhirContext) {
		return theFhirContext.newRestfulGenericClient(INTERNAL_FHIR_BASE_URL);

	@Bean(name = "externalFhirClient")
	public IGenericClient getExternalFhirClient(
		@Qualifier("interceptorFhirContext") FhirContext theFhirContext) {
		return theFhirContext.newRestfulGenericClient(EXTERNAL_FHIR_BASE_URL);

	@Bean(name = "patientMDMInterceptor")
	public PatientMDMInterceptor getPatientMDMInterceptor(
		@Qualifier("internalFhirClient") IGenericClient theInternalFhirClient,
		@Qualifier("externalFhirClient") IGenericClient theExternalFhirClient) {

		return new PatientMDMInterceptor(theInternalFhirClient, theExternalFhirClient, myDaoRegistry);

Here is a sample MDM Rule Definition Script that could be used to test PatientMDMInterceptor.

  "version" : "1",
  "mdmTypes" : [ "Patient" ],
  "candidateSearchParams" : [ {
    "resourceType" : "Patient",
    "searchParams" : [ "identifier" ]
  }, {
    "resourceType" : "Patient",
    "searchParams" : [ "birthdate" ]
  } ],
  "candidateFilterSearchParams" : [ ],
  "matchFields" : [ {
    "name" : "patient-birthdate-match",
    "resourceType" : "Patient",
    "resourcePath" : "birthDate",
    "matcher" : {
      "algorithm" : "STRING",
      "exact" : "true"
  }, {
    "name" : "patient-last-name-match",
    "resourceType" : "Patient",
    "resourcePath" : "",
    "matcher" : {
      "algorithm" : "STRING",
      "exact" : "false"
  }, {
    "name" : "patient-first-name-match",
    "resourceType" : "Patient",
    "resourcePath" : "name.given",
    "matcher" : {
      "algorithm" : "STRING",
      "exact" : "false"
  }, {
    "name" : "patient-id-ssn-match",
    "resourceType" : "Patient",
    "resourcePath" : "identifier",
    "matcher" : {
      "algorithm" : "IDENTIFIER",
      "identifierSystem" : ""
  } ],
  "matchResultMap" : {
    "patient-birthdate-match,patient-last-name-match,patient-first-name-match" : "MATCH",
    "patient-id-ssn-match" : "MATCH"

Here is a sample MDM Survivorship Script that could be used to test PatientMDMInterceptor.

// Global handler
// This function will be called by MDM module to determine which attributes are replaced
// and which are preserved in the golden record.
// It modifies the current golden record based on the target record found.
function mdmApplySurvivorshipRules(targetRec, goldenRec, txContext) {
    // Replaces all values in the golden resource with the values in the target resource.
    // But IDs, identifiers and metadata are not replaced.
    var helper = new MdmHelper(Fhir.getContext(), targetRec, goldenRec, txContext);
    // Now copy new identifiers and update current ones per system in the golden record.
    for (let i = 0; i < targetRec.getIdentifier().size(); i++) {
        let targetId = targetRec.getIdentifier().get(i);
        let goldenId = getIdentifier(goldenRec, targetId.getSystem());
        if (goldenId === null) {
        } else {

function getIdentifier(resource, system) {
    // get first identifier using the system from resource identifiers
    for (let i = 0; i < resource.getIdentifier().size(); i++) {
        var id = resource.getIdentifier().get(i);
        if (id.getSystem().equals(system)) {
            return id;
    return null;

// This function will be called by MDM module to merge two golden records, when needed.
function mdmApplySurvivorshipRulesOnMergeGoldenResources(targetRec, goldenRec, transactionContext) {
   // merge all fields by default
   var helper = new MdmHelper(Fhir.getContext(), targetRec, goldenRec, transactionContext);