BENBUN Coder
BENBUN Coder

Reputation: 4881

Constraining the use of Resources in FHIR

For a given implementation scenario is it acceptable to limit how resources are used within the system in ways not described by resource profiles.

A number of scenarios :

 -  explicitly prohibit the use of <contained> resources
 -  explicitly prohibit the use of <modifierExtensions>
 -  explicitly prohibit the use of the narrative <text>

Validation on the system could clearly implement the above, but is there away of advertising this restriction on say an "implementation conformance profile"?

Upvotes: 0

Views: 420

Answers (3)

Ewout Kramer
Ewout Kramer

Reputation: 1004

Profiles don't say anything about which resources are used general, as in "which resource are supported by a FHIR endpoint or client", since that would be for that server or client to decide. And they report such capabilities in their Conformance statement.

Profiles can limit the resources involved when communicating data between partners: For example, an Observation may normally refer to Patient, Group, Device or Location in its 'subject' property. You may limit these to a subset, and by doing this consistently across Resources, you are effectively restricting the set of Resources exchanging trading partners need to "know" about when they use that Profile (and only that profile).

I think your second bullet misses some text, so I can't comment on that one.

The spec says about Narrative:

Resources SHOULD always contain narrative to support human-consumption as a fallback. However, in a strictly managed trading systems where all systems share a common data model and additional text is unnecessary or even a clinical safety risk, the narrative may be omitted."

If you look at the base profile definitions of a given resource (look at http://www.hl7.org/implement/standards/fhir/observation.profile.xml.html) for example, you'll see that Observation.text is defined there with cardinality 0..1, you may profile this to 0..0 to make this explicit in your profile.

Here's an example Profile showing the tools there are, including Lloyd's suggestion to use XPath:

<Profile xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../schema/profile.xsd">  
  <!-- stuff removed -->
  <structure>
    <type value="Observation"/>
    <name value="MyConstrainedObservation"/>
    <publish value="true"/>
    <!-- again, elements left out -->
    <element>
      <path value="Observation" />
      <constraint>
        <key value="shorttext" />
        <severity value="error" />
        <human value="Must be short text" />
        <xpath value="string-length(f:text) < 100" />
      </constraint>              
    </element>
    <element>
      <path value="Observation.modifierExtension"/>
      <definition>
        <min value="0" />
        <max value="0" />
      </definition>
    </element>
    <element>
      <path value="Observation.text"/>
      <definition>
        <short></short>
        <formal></formal>
        <min value="0" />
        <max value="1" />
        <condition value="shorttext" />
      </definition>
    </element>
    <!-- elements left out -->
    <element>
      <path value="Observation.subject"/>
      <definition>
        <type>
          <code value="Resource(Patient)"/>
          <aggregation value="bundled" />
          <aggregation value="referenced"/>
        </type>       
      </definition>
    </element>
    <!-- more stuff -->
  </structure>
</Profile>

This profile first defines an XPath constraint limiting the length of a text (just as an example), and goes on to limit the cardinality of Observation.modifierExtension to 0..0, effectively forbidding its use. Furthermore, it limits Observation.subject to only reference Patients (thus you might avoid the use of Device etc. in your exchanges) and specifies that those Patients can only be referenced or bundled (in a message, document or transaction), but may not be included using .

Obviously, what I did here can be done with Observation.text and Observation.contained too. You have both structural (cardinality) and executable (xpath) means to limit the content at your disposal.

Upvotes: 1

Lloyd McKenzie
Lloyd McKenzie

Reputation: 6793

In profiles, it's also possible to constrain any of these elements through the use of Profile/structure/element/definition/constraint. For example, to prohibit narrative on Patient, you would define a Profile with a structure of type "Patient" and on the root "Patient" element, include a constraint with the xpath "not(f:text)"

This would still need to be done on a per-resource basis though.

Another option would be to define an isModifier extension on your Conformance resource which declares that you don't support isModifier or text or whatever on any resources. Though in practice, that's just going to mean most systems won't know how to read your Conformance resource and thus won't know how to talk to you at all.

Some advice: Keep in mind that any such restrictions are greatly going to limit your ability to interoperate with the broad community, though they could potentially be appropriate in very limited environments.

With isModifier, there's general recognition that most systems will reject instances containing an isModifier they don't recognize, so if you don't recognize any modifier extensions, rejecting instances that contain them doesn't require any special declaration - it's normal behavior.

As for text, it may be better to place a constraint that says that narrative must be generated rather than prohibiting it altogether. Generated narrative can be safely ignored and you're much more in the spirit of FHIR conformance doing that than rejecting instances with any narrative at all.

Upvotes: 0

Howard Edidin
Howard Edidin

Reputation: 63

I believe you would add this to your conformance document

Upvotes: 0

Related Questions