[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [COAS-List] SGML Thread on Report Types
> -----Original Message-----
> From: Tim Brinson [SMTP:tim@protocol.com]
> Sent: Wednesday, November 04, 1998 9:25 AM
> To: Wayne Wilson
> Cc: coas@cs.fiu.edu
> Subject: Re: [COAS-List] SGML Thread on Report Types
>
> Wayne Wilson wrote:
> > BUT, one movement afoot is to provide each report with structure, ala a
> > DTD. Then one can standardize on DTD's (or not!). Another approach
> > with XML is based on HyTime where any number of reports can be
> > dynamically defined according to a standardized meta-structure
> > represented by a DTD! (this is the architecture Rachel refers to in her
> > discussion with Wes.) In fact, I would submit this a crux of the
> > discussion thread: should we exhaustively enumerate and standardize
> > DTD's for all medical reports or should we standardize on a mechanism
> > allowing us to dynamically create and define and use any number of
> > reports (and their labels)?
>
> I have seen Rachael present on Kona a number of times (but some time
> ago). I never understood the "architecture" thing except that it is
> suppose to provide the ability to transform content between documents
> with different formats/structure (i.e. DTDs). Now that I can read DTDs
> I need to revisit it. One of the things I'm missing is how SGML
> architectures are suppose to work operationally. I understand how
> normal DTDs are suppose to work with XML but is seems these
> architectural DTDs are more meta information and I don't know when they
> come into play (e.g. compile time, run time, rendering time, document
> creation time, only when a translation between known DTD are needed, or
> what ever).
>
Let me see if I can give a quick overview of architectures.
SGML architectures are a way of relating DTD's, in effect, saying that DTD B
is a special case of DTD A More correctly, they are a way of saying that
individual elements in DTD B are special cases of individual elements in DTD
A. [SGML (and XML) has no way of "sub-classing" element definitions or DTDs;
architectures are one approach to getting some of that functionality].
What the HL7 Patient Record Architecture (PRA) proposal ("the proposal
formerly known as KONA") is doing with them is the following. We are
defining a few (with an emphasis on FEW) DTD's which are very general and
represent the basic structure of healthcare documents, these form the basis
of the "levels" in PRA, with higher numbered levels having a more fine
grained structure (i.e., Level 1 is "largely" concerned with specifying
enough structure so that a remote system will be able to display the
document). These DTDs are the "architectural" or meta-DTDs. Each of these
architectural DTDs is just a normal DTD (in truth, the Level 3 DTD will
serve as an architectural DTD for Level 2, which will serve as an
architectural DTD for Level 1).
Now, suppose you are vendor whose system generates XML radiology reports.
You have defined your own radiology report DTD, which has nice "hooks" for
special features of your authoring/browsing system. However, you want to
allow your customers to share the documents they create with your system
with other folks who may not have access to your system (and whose system(s)
might be confused by the XML elements in your documents which are the
"hooks" for you cools feature set).
What you do, is you provide a mapping between individual elements in your
vendor DTD and individual elements in the standard PRA DTD. The mapping is
expressed IN YOUR VENDOR DTD as #IFXED attribute values (example to follow
at the end). An "architecture engine" is then able to transform instance
documents which conform to your vendor DTD into instance documents which
conform to the standard PRA DTD by "looking up" the mapping between elements
in your vendor DTD. In practice, your system might have an "export"
command, which performs this transformation.
I think the power of this approach is two fold. First, it allows tools to
be built that know how to process and operate on instance documents
conforming to "standard" DTDs, and these tools will still be able to process
vendor-specific instance documents, providing the vendor has provided the
mapping to the standard DTD. Granted, these tools won't be able to do ALL
that the vendor system could do and won't be able to extract every bit of
"semantics" out of the transformed documents that the vendor system could
from the original documents. But, that's a small price to pay for the
"mid-level" oif interopability that it does support.
In order to understand the second win of this approach, you have to first
ask yourself, "why couldn't I just write my own transformation program and
achieve the first benefit, without having to learn about these architecture
things?" Good question! In fact, that's very true. In the abstract, an
architecture is just a mapping of elements from one DTD into elements of
another DTD and there's no reason why I couldn't sit down and in short order
knock off a quick perl script which did the transformation.
The win of architectures is the following: if I'm using off-the-shelf
architecture engine (such as James Clark's SP), I don't have to write a line
of code myself! All I have to do is add a few #FIXED attributes to my DTD
and I'm done! In essence, the use of specific #FIXED attributes in the
vendor DTD is a form of "declarative" programming: nice, clean, easy,
maintainable, etc.
Here's the example. Suppose my vendor system spits out radiology reports
which conform to the following (simplified) DTD.
<!-- radiologyreport.dtd -->
<!ELEMENT RadiologyReport
(PatientInfo, ClinicalData,
Procedure, Findings, Impressions,
Recommendations)>
<!ELEMENT PatientInfo
(Name, MRN, DOB)>
<!ELEMENT Name (#PCDATA)>
<!ELEMENT MRN (#PCDATA)>
<!ELEMENT DOB (#PCDATA)>
<!ELEMENT ClinicalData (#PCDATA)>
<!ELEMENT Procedure (#PCDATA)>
<!ELEMENT Findings (#PCDATA)>
<!ELEMENT Impressions (#PCDATA)>
<!ELEMENT Recommendations (#PCDATA)>
<!-- end of radiologyreport.dtd -->
Here's a sample instance document which conforms to this DTD.
<!-- radiologyreport.xml -->
<?xml version="1.0"?>
<!DOCTYPE RadiologyReport SYSTEM "radiologyreport.dtd">
<RadiologyReport>
<PatientInfo>
<Name>Henry Levin, the 7th</Name>
<MRN>123456789</MRN>
<DOB>May 13, 1923</DOB>
</PatientInfo>
<ClinicalData>
History of smoking for 40 years.
</ClinicalData>
<Procedure>
Chest X-ray
</Procedure>
<Findings>
Comparison is made with a chest-x-ray done 6 months ago.
The 1cm nodule previously noted in the right lower lobe
is larger, approximately 1.8 cm. The nodule is round,
with no calcification. There is no adenopathy. Heart size
and bony structures are normal.
</Findings>
<Impressions>
RLL nodule, suggestive of malignancy. Compared
with a prior CXR from 6 months ago, nodule size
has increased.
</Impressions>
<Recommendations>
I notified the ordering physician of this finding by phone.
</Recommendations>
</RadiologyReport>
<!-- end of radiologyreport.xml -->
Suppose further, that we've got a (again, simplified) PRA Level 1 DTD such
as (which says, that a LevelOne document contains a simple header, and one
or more sections):
<!-- Level1.dtd -->
<!ELEMENT LevelOne (header, section+)>
<!ELEMENT header (name?, identifier?, birthdate?)>
<!ELEMENT section (#PCDATA | other)*>
<!ELEMENT name (#PCDATA)>
<!ELEMENT identifier (#PCDATA)>
<!ELEMENT birthdate (#PCDATA)>
<!ELEMENT other (#PCDATA)>
I could then modify my vendor DTD as follows, to specify the mapping between
elements like <PatientInfo> and <header> or <Findings>,<Recommendations>,
etc. and <section>.
<!-- arch-radiologyreport.dtd -->
<!-- the following XML processing instruction is read my the architecture
engine to know what attributes to
-- look for in the DTD below to perform certain types of mappings:
-- name: specifies the architecture we're mapping to, i.e. look for an
attribute by this name, and map
-- to the element given in the #FIXED value
-- dtd-system-id: the architectural or meta-DTD
-->
<?IS10744:arch
name="LevelOne"
dtd-system-id="level1.dtd"
?>
<!ELEMENT RadiologyReport (PatientInfo, ClinicalData,
Procedure, Findings, Impressions, Recommendations)>
<!ATTLIST RadiologyReport LevelOne NMTOKEN #FIXED "LevelOne">
<!ELEMENT PatientInfo (Name, MRN, DOB)>
<!ATTLIST PatientInfo LevelOne NMTOKEN #FIXED "header">
<!ELEMENT Name (#PCDATA)>
<!ATTLIST Name LevelOne NMTOKEN #FIXED "name">
<!ELEMENT MRN (#PCDATA)>
<!ATTLIST MRN LevelOne NMTOKEN #FIXED "identifier">
<!ELEMENT DOB (#PCDATA)>
<!ATTLIST DOB LevelOne NMTOKEN #FIXED "birthdate">
<!ELEMENT ClinicalData (#PCDATA)>
<!ATTLIST ClinicalData LevelOne NMTOKEN #FIXED "section">
<!ELEMENT Procedure (#PCDATA)>
<!ATTLIST Procedure LevelOne NMTOKEN #FIXED "section">
<!ELEMENT Findings (#PCDATA)>
<!ATTLIST Findings LevelOne NMTOKEN #FIXED "section">
<!ELEMENT Impressions (#PCDATA | HistoricalProcedure)*>
<!ATTLIST Impressions LevelOne NMTOKEN #FIXED "section">
<!ELEMENT Recommendations (#PCDATA)>
<!ATTLIST Recommendations LevelOne NMTOKEN #FIXED "section">
<!-- end of arch-radiologyreport.dtd -->
Then, without writting a line of code, I can transform the radiology
instance document above into the following one:
<!-- radiology report conforming to Level1.dtd -->
<?xml version="1.0"?>
<!DOCTYPE LevelOne SYSTEM "level1.dtd">
<LevelOne>
<header>
<name>Henry Levin, the 7th</name>
<identifier>123456789</identifier>
<birthdate>May 13, 1923</birthdate>
</header>
<section>
History of smoking for 40 years.
</section>
<section>
Chest X-ray
</section>
<section>
Comparison is made with a chest-x-ray done 6 months ago.
The 1cm nodule previously noted in the right lower lobe
is larger, approximately 1.8 cm. The nodule is round,
with no calcification. There is no adenopathy. Heart size
and bony structures are normal.
</section>
<section>
RLL nodule, suggestive of malignancy. Compared
with a prior CXR from 6 months ago, nodule size
has increased.
</section>
<section>
I notified the ordering physician of this finding by phone.
</section>
</LevelOne>
<!-- end of radiology report conforming to level1.dtd -->
Does that help? For further info, you might want to check out the following
resources on architectures:
http://www.isogen.com/papers/archintro.html
http://www.megginson.com/XAF/
Furthermore, myself, Dr. Robert Dolin and Jason Williams are teaching an XML
Tutorial at Fall AMIA (all day on Sat., Nov 7), where we will talking
*about* architectures, but not going into too much technical detail.
Also, there's all of the talk in the XML world of needing a new "schema
definition language" to replace DTDs. Chief among the noted limitations of
DTD (in content and syntax) is the inability to "sub-class" elements. This
capability will very likely make it into whatever recommendation the W3C
produces in this regard (see http://www.w3.org/XML/Activity.html, the
section on "XML Schema Working Group"). Its unclear at this point, but my
guess is that ALL of the functionality of architectures will become part of
that recommendation.
Paul V. Biron
SGML Business Analyst, Kaiser Permanente
Member, KONA Editorial Group, HL7 SGML/XML SIG
p.s. Also, a few things to note. Architectures are not formally defined at
the moment for XML, only for SGML. SGML architecture declarations use a
feature of SGML (NOTATION attributes) which was left out of XML; the use of
the processing instruction above (<?IS10744:arch ... ?>) is the *proposed*
mechanism for declaring architectures in XML, the proposal has been sent to
vote and we're just waiting on the results. Also, the public release of SP
does NOT currently support this proposed architecture declaration syntax.