in the US, real-time data on Emergency Medical admissions and causes is collected by National Emergency Medical Services Information System (NEMSIS). Schematron has allowed them a practical route to having subject-matter experts specify rules in plain English, then developers implement exactly those rules. Read their excellent Schematron Guide, or see their online Library of national and state-level Schematron Rules. (Hint: try “PA”)
Glancing over some of the rules, we can see that they have three parts: the US State name(s), the text, and a severity indicator: Warning, Error, Fatal
In the rules we can see seven different styles being used:
- Declarative: “ Triage Classification for MCI Patient should be recorded when Mass Casualty Incident is “Yes”.”
- Instructive: “When administering Narcan you must document a pre & post administration GCS.“
- Minimal: “ The procsDone custom element value is not correct”
- Impactive: “ The Role/Type of Person performing the airway procedure is not allowed to perform this skill.“
- Corrective: “ If there was a vehicle collision you must indicate if there was airbag deployment or You have indicated Other without providing an explanation in the other field, Or you have conflicting information in the airbag field“
- Descriptive: “How many shocks were delivered“
- TIghtly Coupled: “ Date/Time of Symptom Onset (eSituation.01) should equal a valid value other than a Not Value when any of the following conditions are met:
- -Destination Team Pre-Arrival Activation (eDisposition.24) equals any ‘Yes’ value;
- -Primary Symptom (eSituation.09) equals an ICD-10-CM Diagnosis Code;
- -Chief Complaint Anatomic Location (eSituation.07) equals a valid value other than a Not Value;
- -Chief Complaint Organ System (eSituation.08) equals a valid value other than a Not Value”
Now there is at least one more style of wording I sometimes see in assertion, which they do not do. This is to report what was found without comment, one the grounds that the error is obvious:
- Reportive: (made up) “The patient is described as having 10 legs“
Which is better? Only an idiot would comment on this without knowing the systems, UIs, user expectations, and other pragmatic issues: which I do not. For all I know, in fact, all these approaches are optimal in their particular situations. There are always reasons for things (in particular, where some pre-made independent efforts must be coalesced, of course there will be different approaches, and of course some of them may not be ideal fits for the system that emerges.)
Perhaps what these different approaches (there may be more!) hint at is that starting off with shared guidelines about which approaches are useful, moderately applied, can be good. (For all I know, they did.) But then we come to the knowledge extraction problem…
The thing is that it is very difficult, with any committee or experts, to stop concrete thinking and get declarative statements. People think better with some scenario, such as “The worker clicks “Yes” here and some check should be applied and some information given to them: what is the appropriate information?” But then the information may be given in terms of some interface that does not exist, or may be expressed in a way that does not capture the “business requirement” well.
Indeed, I know of one standards effort, which made a local national standard schema in a financial area, where the facilitators had to, eventually, actually ban any use of schemas or content models in the committee: because otherwise the focus went on the artifact and fascinating trivialities such as order, rather than capturing a tractable and applicable description of the semantics.
Here is the point of this post: perhaps what is needed is not always just to find the best style from those above, perhaps the best approach may be to have text/markup that provides the information of all the styles (that are relevent in your situation.
Now, in general, a Schematron assert is best expressed as a positive statement: I recommend “A should be B, because of C, but instead found D. ” This has the declarative, and ideally the instructive and reportive styles. (What I try to fight against, in general, is using assertions like printf debug statements: “ERROR: found X”. That is not a schema, it does not try to capture the requirement in an application-neutral way.)
But the more that the schema is designed to be used in a User Interface or protocol, the more that impactive/instructive/corrective styles may be desireable.
Aside: Let me note here that Schematron lets you get quite rich messages, apart from @role to say the severity level (or whatever you like), it has @see allowing the message to be linked to some URL for explanation, and the ability to link to an appropriate icon or graphic with @icon! All these are useful for helping humans.
But we can have our cake and eat it too: Schematron allows assert and report elements to be linked to their own diagnostics elements. One use of these is to provide rich dynamic text (and a icon, link, etc. of course) that some particular application needs.
Using diagnostics, we can have a full gamut of information, from all the styles:
- Assertion: “ A should be B, because of C” – general statement, direct from subject matter experts
- Diagnostic: “Found D. You need to be set up to do E next, Thus will block F external outcome. To fix: do G.”
Now, indeed, a single assertion can have multiple diagnostics, which you can chunk together in blocks. You might use this, for example, to provide the information in Spanish. Or you might have different sets of diagnostic texts optimized for different users, different responsibility levels, the names used in different regions or PDA apps, etc.
This is a real strength in Schematron, over (AFAIK) every other schema language and over many rules languages (or expert systems, as we used to call them: yes a Schematron schema is an expert system): it takes as its base that there a multiple stakeholders involved (human and computerized), and each of these may really benefit from information directed at their capabilities and terminology and roles.
For information for humans to read or hear, use diagnostic elements; for information for computers to use, use property elements; to get a richer user experience, use the @icon and @see attributes. But you can use Schematron simply without any of these helpful, value-adding features too!