Clinical Decision-Support

Introduction
This tutorial is intended to assist developers in getting started with the SanteDB Protocol Definition XML format, the format in which SanteDB clinical protocol rules are expressed.
What is a Clinical Protocol?
In SanteDB, a clinical protocol is defined as a series of actions that must occur to care for a patient based on a series of entry criteria or rules. SanteDB care planning engine will take one or more protocols for a patient to generate a proposed plan of care for that patient.
Each clinical protocol is defined as a separate series of clinical events that must occur, you don't have to worry about bundling them together. For example, if you are writing a series of clinical protocol rules for DTaP and ROTA you could (and should) seperate out the domains of that protocol.
How does SanteDB use these protocols?
Whenever a function calls the CarePlanning service, the SanteDB back end will contact the clinical protocol repository to gather a list of IClinicalProtocol implementations to be executed (the XML protocol handler is one of these implementations, but there are others). The care planner then executes the logic in the clinical protocol files asynchronously collecting the results in a CarePlan instance.
If the caller requested that the care planner create proposed encounters (appointments) then the care planner will group the proposed actions in the CarePlan as a periodic hull function of the StartTime - Coalesce(StopTime, ActTime).
Understanding MoodConcepts
Before we begin writing our clinical protocols, we first have to understand an often overlooked attribute on all SanteDB objects, the MoodConcept. The MoodConcept is described in more detail in the schema and technical documentation, however it will be summarized here for brevity.
All Acts in SanteDB carry with them a mood concept, this instructs data consumers the mode of the data. The most common mood concept are:
Mood concept
Description
EventOccurence
Indicates that the act did occur, meaning something was actually done to the patient.
Intent
Indicates that the act is something that someone intends to do in the future
Request
Indicates that the act is something that a human is requesting be done at a later time
Propose
Indicates that the act is something that is being proposed to be completed
For the care planner and clinical protocols, we look to the Propose mood concept, as the computer and our protocols are simply proposed steps in a care plan.
Setting up your Materials or other required assets
Please note that SanteDB does not treat a vaccination protocol differently than any other clinical protocol. This means that if you ware setting up a clinical protocol which relies on materials, places, or other entities, you must ensure that those entities are created appropriately. This can be done using the user interface, or alternately using a dataset file.
The CDSS XML Format
Clinical protocols are defined in the protocols/ directory of an applet. When this applet is uploaded to the IMS, it will install the protocol into the IMS and distribute the protocol to all connected clients.
The protocol XML format is described in the ClinicalProtocol.xsd schema distributed with the SDK and can be used by any standard XML editor to provide code completion. In this tutorial we will be using Microsoft Visual Studio to do this editing.
Creating your protocol file
For this tutorial, we're going to do protocol for a fake HepA+HepB dualvalent adult schedule which requires three doses. (Note: This is not medically accurate, and is for illustrative purposes). The dosing schedule looks like this:
d1 = p.dob + ('9yr' .. )
d2 = d1.time + ('1mo' .. '1yr'),
d3 = d2.time + ('1yr' .. '3yr')
Basically in human terms:
Dose 1 can occur anytime after the patient's 9th birthday
Dose 2 should occur 1 after after dose 1 but is still effective if given up to one year
Dose 3 should occur 1 year after Dose 1 but is no longer effective if given 3 years after dose 1.
The first thing we will do is create a new XML file in our applet project under protocols/. The name can be anything but it is good practice to use the format:
[jurisdiction].protocol.[type].[class].xml
Given that, if we're in Elbonia (our fake jurisdiction) the filename would be
el.protocol.vacc.hepabdvalent.xml
The next thing we want to do (to make our editing easier) is to add a reference to the ClinicalProtocol.xsd schema.
We now can create the start of our XML protocol:
1
<?xml version="1.0" encoding="utf-8" ?>
2
<ProtocolDefinition xmlns="http://santedb.org/cdss">
3
​
4
</ProtocolDefinition>
Copied!
Identifying your Protocol
Whenever SanteDB creates an Act based on the suggestion of a clinical protocol, or whenever it is installing your applet, it needs to assign a unique identifier to the protocol for linking. The four attributes that control this behavior are:
id - The developer friendly name for the protocol like MyProtocol1
name - The human friendly name for the protocol like HepA+HepB Dualvalent
uuid - The universally unique name for the protocol (a UUID)
version - The version of the protocol represented in the file.
After adding these your protocol should look like this:
1
<ProtocolDefinition xmlns="http://santedb.org/cdss" 
2
                    id="aa_hebab2valent"
3
                    name="Elbonia HepA+HepB 3 Dose Standard Schedule"
4
                    uuid="6DFCA6C8-5934-4D7E-9469-EDBAB3983888"
5
                    version="1.0.0.0">
Copied!
Important: The UUID must be unique. Don't just copy/paste them from examples or other protocols. If you change a protocol you must change the UUID.
Identifying Entry Criteria
Next, we have to determine who we even want to apply this protocol to. The entry criteria could be:
Mandatory - In which case we want to define the entry criteria for populations which must have the schedule applied (for example: All FEMALES must have HPV)
Optional - In which case subsequent doses are based off the first.
For our example, we're going to say that this HepA+HepB vaccination is optional. This means that we only want to schedule Dose #2 and Dose #3 if Dose #1 was given.
Note: Our dosing schedule says that we can only apply it to patients who are 9 or older, however that is validation rather than planning, so that type of validation rule would go in the business rules JavaScript file to prevent administration of that particular vaccination.
To do this we create a <when> tag on our protocol. The WHEN tag can use HDSI expressions or simple LINQ expressions. Our entry criteria is:
When the patient was involved in a SubstanceAdministration where the product given was this particular type of vaccine
note: You can also base your condition on Consumable rather than Product if you care which brand the previous vaccination was
When the dose sequence of that administration was 1.
1
  <when>
2
    <hdsiExpression>
3
      participation[RecordTarget].target.participation[Product].target.typeConcept.mnemonic=VaccineType-HepAHepB&amp;
4
      participation[RecordTarget][email protected]=1
5
    </hdsiExpression>
6
  </when>
Copied!
If the schedule was mandatory we might do something like this:
1
  <when>
2
    <!-- Patient is 9 years old -->
3
    <linqExpression>now.Subtract(DateOfBirth.Value.Date).TotalDays &gt;= 3285</linqExpression>
4
  </when>
Copied!
Define the rule for Dose #2
Next we have to define a step in our clinical protocol. This is known as a rule. Rules are expressed in common when/then notation. Again the when clauses can use HDSI query or LINQ to filter.
When we look at our Dose 2 logic it was:
d2 = d1.time + ('1mo' .. '1yr'),
So we want to say that when:
The time that the patient has received the first dose of the vaccination where
The product given was HepA+HepB vaccine, and
The dose sequence was 1, and
The dose was actually given (not negated)
We also don't want to propose duplicates, so we should also make a rule that the patient has not received a vaccination where:
The product given was HepA+HepB, and
The dose sequence was 1, and
The dose was actually given
We could get more fancy to say if they showed up and were explicitly not given Dose #2 (i.e. they showed to an appointment but there was a stock out), or if the patient has a known intolerance we shouldn't schedule this, but for now we'll keep the example simple.
1
  <rule id="HEPAB_2" name="HepA+HepB Second Dose">
2
    <when evaluation="and">
3
      <!-- Patient DID Receive Dose #1 -->
4
      <hdsiExpression>
5
        participation[RecordTarget].target.participation[Product].target.typeConcept.mnemonic=VaccineType-HepAHepB&amp;
6
        participation[RecordTarget][email protected]=1&amp;
7
        participation[RecordTarget].target.isNegated=false
8
      </hdsiExpression>
9
      <!-- Patient DID NOT Receive Dose #2 -->
10
      <hdsiExpression negationIndicator="true">
11
        participation[RecordTarget].target.participation[Product].target.typeConcept.mnemonic=VaccineType-HepAHepB&amp;
12
        participation[RecordTarget][email protected]=2&amp;
13
        participation[RecordTarget].target.isNegated=false
14
      </hdsiExpression>
15
    </when>
16
  </rule>
Copied!
Define the "then" if Dose #2 should be proposed
The 'then' logic on a rule indicates what should happen if the "when"condition was successful. Here there are two steps, one where we define a template of something to propose be done, and the other where we set dynamically the properties on that object.
1
    <then>
2
      <action>
3
        <jsonModel>
4
          <![CDATA[
5
            {
6
              "$type": "SubstanceAdministration",
7
              templateModel: {
8
                  mnemonic: "act.substanceadmin.immunization"
9
              },
10
              "moodConcept": "ACF7BAF2-221F-4BC2-8116-CEB5165BE079",
11
              "typeConcept": "F3BE6B88-BC8F-4263-A779-86F21EA10A47",
12
              "statusConcept" : "c8064cbd-fa06-4530-b430-1a52f1530c27",
13
              "doseSequence": 2,
14
              "doseQuantity" : 1.0,
15
              "doseUnitModel" : {
16
                "id": "a4fc5c93-31c2-4f87-990e-c5a4e5ea2e76",
17
                "mnemonic" : "UnitOfMeasure-Dose"
18
              },
19
              "routeModel" : {
20
                "id": "d594f99f-0151-41a0-a359-282ab54683a1",
21
                "mnemonic": "RouteOfAdministration-IM"
22
              },
23
              "siteModel" : {
24
                "id": "1edc643d-a93a-47ed-8737-06ede53d0e1f",
25
                "mnemonic": 'Site-RightArm'
26
              },             
27
              "participation": {
28
                "Product": [{
29
                  "player" : "6CD437C5-E9C2-4259-AA73-6BE768BA3FC0"
30
                 }]
31
               }
32
             }
33
          ]]>
34
        </jsonModel>
35
      </action>
36
    </then>
Copied!
Note: The player of 6CD437C5-E9C2-4259-AA73-6BE768BA3FC0 is a fake UUID, you would substitute a valid material's product key here.
This will setup the static object, now we want to have some logic that will update the start/stop time of the dose based on our previous expression. To do this we use <assign>. Be default the current scope of Assign is the same as the when condition (the patient) but we need to change this since we'll be setting properties based on dose 1. To do that we need to set the three properties of assign:
propertyName Which identifies the property in the proposed object we want to change
scope Which identifies the scope property we want to use
where Which allows us to filter to a particular object in the scope array
1
        </jsonModel>
2
        <assign scope="Participations" where="participationRole.mnemonic=RecordTarget&amp;source.classConcept=932A3C7E-AD77-450A-8A1F-030FC2855450&amp;[email protected]=1&amp;source.participation[Product].player.typeConcept?.mnemonic=VaccineType-HepAHepB" propertyName="StartTime">Act.ActTime.AddMonths(1)</assign>
3
        <assign scope="Participations" where="participationRole.mnemonic=RecordTarget&amp;source.classConcept=932A3C7E-AD77-450A-8A1F-030FC2855450&amp;[email protected]=1&amp;source.participation[Product].player.typeConcept?.mnemonic=VaccineType-HepAHepB" propertyName="ActTime">Act.ActTime.AddMonths(1)</assign>
4
        <assign scope="Participations" where="participationRole.mnemonic=RecordTarget&amp;source.classConcept=932A3C7E-AD77-450A-8A1F-030FC2855450&amp;[email protected]=1&amp;source.participation[Product].player.typeConcept?.mnemonic=VaccineType-HepAHepB" propertyName="StopTime">Act.ActTime.AddMonths(12)</assign>
5
​
6
      </action>
Copied!
Testing your Protocol
The SanteDB SDK provides a utility for testing your clinical protocols before deploying in production. In order to run the debugging tool, you will need a copy of Minims (also in the SDK) database. This allows you to debug your protocols against configured data sources. You can obtain these files by:
Creating a backup from the SanteDB Disconnected Client mobile application
Pointing the database at a configured Minims database (--db=%localappdata%\sdbare\santedb.sqlite). Note this is the default operating mode when launching the application from the start menu.
Creating a new database and using anonymous patients (only recommended for simple protocols)
This tooling is provided by the SanteDB Debug (sdb-dbg) and can be executed by running:
1
> sdb-dbg --db=newdb1.sqlite --xprot
2
​
3
SanteDB Debugger v1.0.0.20334 (Fredericton)
4
Copyright (C) 2015-2019 Mohawk College of Applied Arts and Technology
5
[Warning 2018/01/28 11:41:03] OizDebug.Core.DebugApplicationContext : Can't find the SanteDB database, will re-install all migrations
6
Loading debuggees...
7
Working Directory: C:\Users\justin\Documents
8
Ready...
9
dbg >
Copied!
First we want to open our clinical protocol:
1
dbg >o el.protocol.vacc.hepabdvalent.xml
Copied!
Then we want to test it against a patient. To this we either have to use the scope data query command:
1
dbg >sdq Patient name.component.value=~Justin
2
INF: Patient where o => o.Names.Any(name => name.Component.Any(component => (component.Value.Contains("Justin") == True))) (0..)
3
INF: 1 set to scope
4
dbg >xs [0]
Copied!
Or, we can load a patient from JSON or XML:
1
dbg >sfv Patient mypatient.json
Copied!
Or we can create an instance of an anonymous patient:
1
dbg >ss Patient '{ "dateOfBirth":"2017-01-01" }'
Copied!
Once the scope is set, we can verify the scope by dumping the scope (ds) as XML or JSON
1
dbg >dx
2
<Patient xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://santedb.org/model">
3
  <version xsi:nil="true" />
4
  <sequence xsi:nil="true" />
5
  <classConcept>bacd9c6f-3fa9-481e-9636-37457962804d</classConcept>
6
  <determinerConcept>f29f08de-78a7-4a5e-aeaf-7b545ba19a09</determinerConcept>
7
  <statusConcept xsi:nil="true" />
8
  <template xsi:nil="true" />
9
  <dateOfBirth>2017-01-01</dateOfBirth>
10
  <deceasedDatePrecision xsi:nil="true" />
11
  <genderConcept xsi:nil="true" />
12
</Patient>
Copied!
As JSON the command is:
1
dbg >dj
2
{
3
  "dateOfBirth": "2017-01-01",
4
  "language": [],
5
  "classConcept": "bacd9c6f-3fa9-481e-9636-37457962804d",
6
  "determinerConcept": "f29f08de-78a7-4a5e-aeaf-7b545ba19a09",
7
  "relationship": [],
8
  "$type": "Patient"
9
}
Copied!
Now we can run our clinical protocol to see what is generated
1
dbg >go
2
Complete result set to scope
Copied!
If you want to look at the care plan generated use either "dump scope" (ds) or "dump scope as JSON" (dv or dj)
1
dbg >dj
2
{
3
  "target": {
4
    "dateOfBirth": "2017-01-01",
5
    "language": [],
6
    "classConcept": "bacd9c6f-3fa9-481e-9636-37457962804d",
7
    "determinerConcept": "f29f08de-78a7-4a5e-aeaf-7b545ba19a09",
8
    "relationship": [],
9
    "$type": "Patient"
10
  },
11
  "act": [
12
    {
13
      "$type": "SanteDB.Core.Model.Acts.SubstanceAdministration, SanteDB.Core.Model",
14
      "route": "d594f99f-0151-41a0-a359-282ab54683a1",
Copied!
AngularJS
Business Rules
Last modified 3yr ago
Copy link
Contents
Introduction
What is a Clinical Protocol?
How does SanteDB use these protocols?
Understanding MoodConcepts
Setting up your Materials or other required assets
The CDSS XML Format
Creating your protocol file
Identifying your Protocol
Identifying Entry Criteria
Define the rule for Dose #2
Define the "then" if Dose #2 should be proposed
Testing your Protocol