Re: Implementation comments

Sorry for the delay in responding to your helpful and detailed
message.

A few points:

"Linda Bird" <bird@dstc.edu.au> writes:


> Therefore to represent the foreign key constraint, that the recorder of an
> EHR transaction must be defined in a demographic entity transaction, the
> foreign key field would need to be defined as something like:
> 
> GEHR/event_clinical_transactions/transactions/transaction/versions/transacti
> on/content/[{organiser/}]content_item/context/recorder
> However, as the subpath "organiser" is optional and repeatable, this foreign
> key cannot be represented as an XPath.

Why is 

   GEHR/event_clinical_transactions/transactions/transaction/versions/transaction/content//content_item/context/recorder

not appropriate for your needs?

> In designing the clinical archetypes in XML-Schema the single biggest
> problem we had was:
>         · In order to promote interoperability of health records, we require
> that the GEHR XML instances must conform to the basic building blocks of the
> GOM (using elements such as 'transaction', 'organiser', 'hier_group',
> 'hier_value', etc). Therefore, we needed to ensure that the archetypes could
> be defined as "restrictions" on the complex types found in the GOM
> XML-Schema. This, however, proved to be impossible.
>         In particular, difficulties arose when it was necessary to predefine
> the values that appeared in a list of items. For example, in representing an
> archetype for 'blood pressure', the first value of the proposition must be
> defined as a 'systolic' value, and the second value of this list as a
> 'diastolic' value. However, since it is not possible to repeat an element in
> XML-Schema, it was not possible to express this structural constraint
> naturally. For example, we would have like to be able to say:

<snip/>

> This problem proved to be the single, biggest difficulty in using XML-Schema
> for Electronic Health Records. Because of this problem, XML-Schema could not
> be used as the primary means of defining clinical models in our Health
> record.

It is true that XML Schema cannot impose structural constraints based
on attribute values, either directly, or indirectly as you tried but
were prevented from doing by using multiple restricted sub-types for
the same element.  Why this led you to abandon XML Schema, since DTDs
can't do this _either_, is not clear to me.  In this and other similar 
situations, one obvious strategy is to define the required elements
all with the same, generic, type, and indicate the co-constraint in
both <xs:documentation> and <xs:appinfo>.  Then you can implement
special-purpose post-schema processing validation of your
co-constraints in the short term, and look forward to XML Schema 1.1
which will have co-constraints built in.

> Other problems we had included:
>         · A similar problem occurred when trying to specify some archetype
> constraints. In particular, we often need to restrict the value of a 'TERM'
> to being from a set of valid coded terms - for example, the value of
> "Patient Position" in a blood pressures' protocol must be restricted to one
> of {('Lying', 75, 'GEHR_TermSet-v01'), ('Standing', 76, 'GEHR_TermSet-v01'),
> ('Sitting', 74, 'GEHR-TermSet-v01')}. While XML Schema allows enumeration
> constraints over simple types, there is no similar mechanism to define
> enumerations on complex types.  Therefore it was not possible for us to say
> something like:
>         <complexType name="bpPosition" base="gom: HIER_VALUE" derivedBy="
> restriction">
>             <element name="name" fixed="position"/>
>             <choice>
>                 <element name="value" type="bp:LyingTerm"/>
>                 <element name="value" type="bp:StandingTerm"/>
>                 <element name="value" type="bp:SittingTerm"/>
>             </choice>
>         </complexType>
> Although a number of methods for solving this problem were considered (e.g.
> equivalence classes, extending existing types with new elements, qualifying
> tags), no method was found which would not alter the structure of the
> instance documents, and could be used consistently in all required positions
> within the EHR.

I'm not sure I understand this one, but I think the above comment
applies here too.

>         · Specifying keys and key references were not possible in some cases
> (besides the case of recursion, as described earlier). Clinical archetypes
> are defined at three levels - namely, the transaction, organiser and content
> levels. Transactions contain organisers, which contain other organisers
> and/or content. Therefore transaction archeytpes reference organiser
> archetypes, which reference content archetypes (and other organiser
> archetypes. Now because it was necessary to extend organiser definitions,
> rather than restrict them (to predefine lists of organisers in an 'organiser
> archetype', as per the main problem explained earlier), it is not possible
> for a 'content archetype' to reference the full element path of the elements
> it contains. This is because a 'content archetype' does not know which
> organiser it is contained in (it is the organiser which knows which content
> archetypes can be used within it). This means that it is not possible to
> specify key references inside content archetypes.

I can't follow that without more detail, sorry.   I'm afraid at this
point I don't have time to work through more detail if it were
available, but when we get back to looking at key/keyref for v1.1,
we'll get back in touch with you.

> We believe that the problems that we have encountered in using XML Schema in
> the context of Electronic Health Records are not restricted to our GEHR
> implementation, but will be shared in other approaches and standards. We
> would, however, like to say that, despite the few problems described in this
> letter, we feel quite positive about the XML Schema language as a whole.

Thanks!

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Monday, 12 February 2001 08:53:46 UTC