HL7 Patient Record Architecture
Tutorial
Spring HL7 Meeting
April 27, Toronto
Instructors




Liora Alschuler, Co-chair, HL7
SGML/XML SIG, Chair KEG (“Kona”
Editorial Group), The Word Electric
Bob Dolin, MD, PRA Co-editor, Kaiser
Permanente
Lloyd Harding, PRA Co-editor, IAAI
Jason P. Williams, Oceania Clinical
Information Systems
Tutorial Outline

Overview
– Origin
– Goals & Design Principles
– Theory
– Practice

Implementing the PRA
– Provider perspective
– HIMSS
– Mapping an H&P

Issues in Implementation
Tutorial Materials



Printed handouts
Floppy disk
Website
Overview




Origin of the PRA
Goals & Design Principles
Theory
Practice
Overview
Origin
Goal/ DP
Theory
Practice
Implement
Issues

Pre-HL7
– Document-based exchange
– Value of narrative

Kona and Operation Jumpstart
Overview
Origin
Goal/ DP
Theory
Practice
Implement
Provider
HIMSS
Map
Issues









April, 1996: 1st ad hoc meeting
April–Dec: meet (almost) every month
Oct –Dec: negotiate with HL7
Jan, 1997: 1st meeting as HL7 SIG
July, 1997: Operation Jumpstart at Kona
Mansion, Lake Winnipesaukee, NH drafts
“Kona Architecture”
August, 1997: HL7 SGML Mixer
Sept, 1997: Initial presentation to HL7
Sept, 1998: HL7 adopts XML as V3 msg
syntax
Feb. 1999, HL7 HIMSS demo HL7 XML
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues





Purpose: expand EMR to include document-based
clinical information
– support exchange of documents
– support reuse of documents
– support longevity through system-independent
electronic medical records
Scope: exchange of attested documents
Incremental design and implementation: do simple
things first
Local specialization interacting with global
generalization
Supports broad spectrum of business needs
Overview
Origin
Goal/ DP
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
GOALS (1/2):
• Use open standards.
• Support exchange of documents between
users, including those with different
levels of technical sophistication.
• Give priority to delivery of patient
care.
• Enable a wide range of post-exchange
processing applications
• Promote exchange independent of the
underlying transfer or storage
mechanism.
Overview
Origin
Goal/ DP
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
GOALS (2/2):
•Prepare the design reasonably quickly.
•Enable policy-makers to control their
own information requirements without
extension to this specification.
•Specification of document types for
creation and processing other than for
exchange lie outside the scope of this
effort.
Overview
Origin
Goal/ DP
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
•Design Principles (1/2):
•Shall be compatible with XML and the
HL7 RIM.
•Technical barriers to entry shall be
minimized.
•The architecture shall specify the
document types required for exchange.
•The architecture shall establish
minimal constraints or requirements on
document structure and content required
for exchange.
Overview
Origin
Goal/ DP
Theory
Practice
Implement
Issues
Design Principles (2/2):
•The architecture shall be scalable to
accommodate highly granular markup such as
highly structured text and coded data.
•Document types based on this architecture
shall accommodate such constraints and
requirements as supplied by appropriate
professional, commercial, and regulatory
agencies.
•Documents types for document creation and
processing intended for exchange must map
to the exchange architecture.
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues

The central problem of information
exchange is the tension between:
Local
Global
Specialization
Generalization

In other words, “Why can’t everyone just
agree to do things my way?” is not the
right question.
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
The right question is:
 How can we:
– impose minimal constraints on local
practice
yet...
– ensure that senders and receivers can
share meaning where meaning is, indeed,
shared and can apply common processing
applications based on a well-understood
semantic?
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
The “arch” in PRA



Taxonomy of document types
Classed by type of document
Classed by degree of granularity of
markup
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues

Specifies and allows:
– mapping from sender’s local schema to
standard exchange schema
– mapping between different levels of
markup granularity
– mapping between domain-specific
exchange schemas
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues


Scalable document architecture relates
documents in a hierarchy according to
the degree of encoding
also relates documents with equivalent
granularity of markup but different
languages or terms
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
The “arch” in PRA
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
Extending the PRA
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
Extending the PRA
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
Why an “arch” not a DTD?



Local and exchange requirements vary
Authoring and processing requirements
vary
Simple inheritance between document
types
– levels of granularity
– language
– lateral (domains of clinical practice)
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
Benefits





Information can be encoded at varying levels
of specificity and understood at the highest,
or most appropriate, level of encoding
Information encoded at varying levels can be
analyzed at the highest common level
Where a greater level of specificity is required
than what is presented, there may be value in
the simpler taxonomic categories.
Diverse, local DTDs for document creation,
validation, local processing with minimal
constraint for exchange
Common processing applications in
exchange context
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
Benefits





(Some) preservation of local markup within
exchange document
Scalable wrt DTD complexity
Scalable wrt implementation
Permits added level of abstraction, indirection
in exchange model
Not a winner-take-all approach to single
exchange model; allows distribution of work,
cooperation among standards orgs
Overview
Theory
Exchange
“arch”
Why
Bennies
Practice
Implement
Issues
Benefits



Scalable taxonomy for exchange,
indexing, searching, other processing
applications
Graduated cost/benefit analysis
Graduated levels of conformance
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Header :: Overview
Purpose
Enable clinical document exchange across and within institutions.
Facilitate clinical document management.
Facilitate compilation of an individual's documents into a lifetime EHR.
Principles
Every HL7 Patient Record Document contains a Patient Record Header. The header
contains required information that uniquely identifies and classifies the document,
attestation details, event, patient, and practitioner.
The PRA Header is not intended to replace and does not preclude use of localized
header information or local document management information in either the source or
the interchange documents.
The PRA Header specifies whether a document is an "original", an "addendum", or a
"replacement". Header component "document.parent.id" references the updated
document.
Unique Identifiers
All unique identifiers (components containing ".id") are assigned by the
document.originating.system. To the extent that originating system names are globally
unique, a concatenation of document.originating.system with any unique identifier in the
document header results in a globally unique identifier.
All header components that are unique identifiers contain an element "id.value" in their
content model. For required identifiers, this subcomponent is required.
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Header :: Overview
People involved with a clinical document
A person should be included as the value for each appropriate header component, even if
the person represents the value for more then one component.
Header DTD design principles
Header components are mapped to the RIM, and use HL7 data type definitions.
(Currently, RIM 0.86 and V2.3 data types.)
The following #FIXED attributes are used:
HL7.datatype : the HL7 V2.3 data type of the element.
RIM.attribute : the corresponding RIM attribute.
RIM.version: the RIM version mapped to.
domain: the HL7 table where enumerated values are drawn from.
Where there is a closed enumerated value list (i.e. HL7 V2.3 data type is "ID - coded
values for HL7 tables"), header components are modeled as EMPTY, the set of allowable
values are enumerated in the DTD, and the value is conveyed in an attribute named
"value" (e.g. document.state, patient.sex).
V2.3 data type "IS - Coded values for user-defined tables" is modeled as an HL7 V2.3
"CE - coded element" data type (e.g. document.type, practitioner.role).
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Header :: Current Draft
<LevelOne>
<header>
<document>...</document>
<event>...</event>
<patient>...</patient>
<practitioner>...</practitioner>
</header>
<body>
...
</body>
</LevelOne>
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Header :: Current Draft
<document>
<document.creation.date>19990212</document.creation.date>
<document.id>
<id.value>1009</id.value>
</document.id>
<document.originating.system>
<id.value>systemX</id.value>
<organization.name>Global Healthcare, INC</organization.name>
</document.originating.system>
<document.originator.id>
<id.value>24680</id.value>
<family.name>Levin</family.name>
<given.name>Henry</given.name>
<suffix>the 7th</suffix>
<degree>MD</degree>
</document.originator.id>
<document.state value="original"/>
<document.type>
<identifier>11492-6</identifier>
<text>HISTORY AND PHYSICAL</text>
<name.of.coding.system>LN</name.of.coding.system>
</document.type>
</document>
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Header :: Current Draft
<document>
<document.creation.date>19990212</document.creation.date>
<document.id>
<id.value>1009</id.value>
</document.id>
<document.originating.system>
<id.value>systemX</id.value>
<organization.name>Global Healthcare, INC</organization.name>
</document.originating.system>
<document.originator.id>
<id.value>24680</id.value>
<family.name>Levin</family.name>
<given.name>Henry</given.name>
<suffix>the 7th</suffix>
<degree>MD</degree>
</document.originator.id>
<document.state value="original"/>
<!ENTITY % Time_stamp "( #PCDATA | local.header )*">
<document.type>
(YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ])
<identifier>11492-6</identifier>
<text>HISTORY AND PHYSICAL</text>
<!ELEMENT document.creation.date %Time_stamp;>
<name.of.coding.system>LN</name.of.coding.system>
<!ATTLIST document.creation.date
</document.type>
</document> %common-atts;
HL7.datatype CDATA #FIXED "TS"
RIM.attribute CDATA #FIXED "Clinical_document_header.origination_dt">
Overview
PRA Header :: Current Draft
Theory
Practice
<document>
Header
<document.creation.date>19990212</document.creation.date>
Body
<document.id>
Implement
<id.value>1009</id.value>
</document.id>
Issues
<document.originating.system>
<id.value>systemX</id.value>
<organization.name>Global Healthcare, INC</organization.name>
</document.originating.system>
<document.originator.id>
<id.value>24680</id.value>
<family.name>Levin</family.name>
<given.name>Henry</given.name>
<suffix>the 7th</suffix>
<!ELEMENT document.id %Entity_identifier;>
<degree>MD</degree>
<!ATTLIST document.id
</document.originator.id>
<document.state %common-atts;
value="original"/>
HL7.datatype
CDATA #FIXED "EI"
<document.type>
RIM.attribute CDATA #FIXED "Clinical_document_header.id">
<identifier>11492-6</identifier>
<text>HISTORY AND PHYSICAL</text>
<!ELEMENT document.originating.system %Extended_org_name_and_id;>
<name.of.coding.system>LN</name.of.coding.system>
<!ATTLIST document.originating.system
</document.type>
%common-atts;
</document>
HL7.datatype CDATA #FIXED "XON"
RIM.attribute CDATA #FIXED "Patient_service_location.id">
Overview
PRA Header :: Current Draft
Theory
Practice
<document>
Header
<!ENTITY % document.state.table
<document.creation.date>19990212</document.creation.date>
Body
" ( original
<document.id>
Implement
| addendum
<id.value>1009</id.value>
| replacement )" >
</document.id>
Issues
<document.originating.system>
<id.value>systemX</id.value> <!ELEMENT document.state EMPTY>
<!ATTLIST
document.state
<organization.name>Global Healthcare,
INC</organization.name>
%common-atts;
</document.originating.system>
HL7.datatype CDATA #FIXED "ID.EN"
<document.originator.id>
RIM.attribute CDATA #FIXED ""
<id.value>24680</id.value>
<family.name>Levin</family.name>domain CDATA #FIXED "HL7Z001"
<given.name>Henry</given.name> value %document.state.table; #REQUIRED>
<suffix>the 7th</suffix>
<degree>MD</degree>
</document.originator.id>
<document.state value="original"/>
<document.type>
<identifier>11492-6</identifier>
<text>HISTORY AND PHYSICAL</text>
<name.of.coding.system>LN</name.of.coding.system>
</document.type>
</document>
Overview
PRA Header :: Current Draft
Theory
Practice
<document>
Header
<!ENTITY % Coded_element
<document.creation.date>19990212</document.creation.date>
Body
<document.id> "( identifier?,
Implement
text?,
<id.value>1009</id.value>
name.of.coding.system?,
</document.id>
Issues
alternate.identifier?,
<document.originating.system>
alternate.text?,
<id.value>systemX</id.value>
name.of.alternate.coding.system?,
<organization.name>Global
Healthcare, INC</organization.name>
local.header* )">
</document.originating.system>
<document.originator.id>
<!ELEMENT document.type %Coded_element;>
<id.value>24680</id.value>
<!ATTLIST document.type
<family.name>Levin</family.name>
%common-atts;
<given.name>Henry</given.name>
HL7.datatype CDATA #FIXED "IS"
<suffix>the 7th</suffix>
RIM.attribute CDATA #FIXED Clinical_document_header.type_cd">
<degree>MD</degree>
</document.originator.id>
<document.state value="original"/>
<document.type>
<identifier>11492-6</identifier>
<text>HISTORY AND PHYSICAL</text>
<name.of.coding.system>LN</name.of.coding.system>
</document.type>
</document>
Overview
PRA Header :: Current Draft
Theory
Practice <header>
Header
<document>...</document>
Body
<event>
Implement
<event.id><id.value>1009</id.value></event.id>
<event.date>19990212</event.date>
Issues
</event>
<patient>
<patient.id><id.value>P001</id.value></patient.id>
<patient.name>
<family.name>Lantry</family.name>
<given.name>Connie</given.name>
</patient.name>
<patient.date.of.birth>19630613</patient.date.of.birth>
<patient.sex value="female"/>
</patient>
<practitioner>
<practitioner.id>
<id.value>24680</id.value>
</practitioner.id>
<practitioner.role>
<text>ATTENDING PHYSICIAN</text>
<name.of.coding.system>HL70133</name.of.coding.system>
</practitioner.role>
</practitioner>
</header>
Overview
PRA Header :: Current Draft
Theory
Practice <header>
Header
<document>...</document>
Body
<event>
Implement
<event.id><id.value>1009</id.value></event.id>
<event.date>19990212</event.date>
Issues
</event>
<patient>
<patient.id><id.value>P001</id.value></patient.id>
<patient.name>
<family.name>Lantry</family.name>
<given.name>Connie</given.name>
</patient.name>
<patient.date.of.birth>19630613</patient.date.of.birth>
<patient.sex value="female"/>
</patient>
<practitioner>
<practitioner.id>
<id.value>24680</id.value>
</practitioner.id>
<practitioner.role>
<text>ATTENDING PHYSICIAN</text>
<name.of.coding.system>HL70133</name.of.coding.system>
</practitioner.role>
</practitioner>
</header>
Overview
PRA Header :: Current Draft
Theory
Practice <header>
Header
<document>...</document>
Body
<event>
Implement
<event.id><id.value>1009</id.value></event.id>
<event.date>19990212</event.date>
Issues
</event>
<patient>
<patient.id><id.value>P001</id.value></patient.id>
<patient.name>
<family.name>Lantry</family.name>
<given.name>Connie</given.name>
</patient.name>
<patient.date.of.birth>19630613</patient.date.of.birth>
<patient.sex value="female"/>
</patient>
<practitioner>
<practitioner.id>
<id.value>24680</id.value>
</practitioner.id>
<practitioner.role>
<text>ATTENDING PHYSICIAN</text>
<name.of.coding.system>HL70133</name.of.coding.system>
</practitioner.role>
</practitioner>
</header>
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Header :: Current Draft
"local.header" provides a slot for local (non-exchange related) markup. The default action
for the receiver is to ignore the local.header and its contents. If the sender chooses to replace
the default with the value of 'markup' they are informing the receiver that they think the
content enclosed in the markup may be useful. There is no requirement that the receiver do
anything with the markup and content.
descriptor: describes the local header.
render: may give indication of how the origin would render the content.
<!ELEMENT local.header (#PCDATA | local.header)* >
<!ATTLIST local.header
ignore (all | markup) "all"
descriptor CDATA #IMPLIED
render CDATA #IMPLIED
%common-atts;>
Overview
Theory
Practice
Header
Body
Issues
PRA Body:: Current Draft
Minimal markup
•Minimal amount of markup at level one.
•Prose structures.
•Sections have an optional section.title.
•Sections consist of paragraphs, lists, and tables.
•Sections can nest.
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Body:: Current Draft
Example of sections with titles and paragraphs.
<LevelOne>
<header>...</header>
<body>
<section>
<section.title>ADMITTING PHYSICAL EXAMINATION</section.title>
<section>
<section.title>GENERAL</section.title>
<paragraph>The blood pressure is 170/88, pulse 80 and regular, and
respirations 18. She weighs 240 pounds. </paragraph>
</section>
<section>
<section.title>HEENT</section.title>
<paragraph>Examination of the head is normocephalic. The patient has
bilateral carotid bruit. There is no jugular venous distention or
lymphadenopathy. </paragraph>
</section>
</section>
</body>
</LevelOne>
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Body:: Current Draft
Lists
•A list contains zero or more items followed by an optional list.
•Items can contain zero or more paragraphs followed by an optional list.
•The structure allows nesting of lists.
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Body:: Current Draft
Tables
•The table captures the structural aspects of multi-dimensional tables and
the content relationships.
•Tables contain an optional table.title and one or more fields.
•Fields contain a field.title and a mixture of zero or more fields and cells.
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Body:: Current Draft
Local.markup
•Links are used in a number of elements besides tables. The link
element is similar to an HTML link.
•Local.markup can be used to indicate to the receiver that this
information is not exchange information. The receiver may
optionally use the information.
•Local.markup includes a descriptor and render attribute.
Overview
Theory
Practice
Header
Body
Implement
Issues
PRA Body:: Current Draft
Healthcare.code
•Healthcare.code should be used to derive medically-related in line items
such as coded vocabularies.
•Contains attributes to indicate the code and the coding system.
•A healthcare.code may apply to non-contiguous text through the use of
XML ID/IDREF attributes.
<!ATTLIST healthcare.code
identifier CDATA #REQUIRED
preferred.name CDATA #IMPLIED
name.of.coding.system CDATA #REQUIRED
coding.system.version CDATA #IMPLIED
local.coding.system (Y|N) #REQUIRED
instance.id CDATA #IMPLIED
original.text IDREFS #IMPLIED
>
Overview
Theory
Practice
Header
<LevelOne>
Body
<header>...</header>
Implement <body>
Issues
<section>
PRA Body:: Current Draft
<section.title>ADMITTING PHYSICAL EXAMINATION</section.title>
<section>
<section.title>GENERAL</section.title>
<paragraph>The blood pressure is 170/88, pulse 80 and regular, and
<healthcare.code identifier="9279-1" preferred.name="RESPIRATORY
RATE" name.of.coding.system="LN" local.coding.system=“N”> respirations
</healthcare.code> 18. She weighs 240 pounds. </paragraph>
</section>
<section>
<section.title>HEENT</section.title>
<paragraph>Examination of the head is normocephalic. The patient has
bilateral<healthcare.code identifier="F-F5480" preferred.name="carotid
bruit" name.of.coding.system="SN3" local.coding.system=“N”> carotid
bruit </healthcare.code>. There is no jugular venous distention or
lymphadenopathy. </paragraph>
</section>
</section>
</body>
</LevelOne>
Overview
Theory
Practice
Implement
Issues

Implementing the PRA
– Provider perspective
– HIMSS
– Mapping an H&P
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
Provider perspective





Analyze local requirements
Document analysis and DTD creation
Document generation & markup
Document management & processing
Document display & transmission
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
Stakeholder_identifier
id : ST
identifier_type_cd : ID
is_assigned_to 0..*
is_assigned 1
Stakeholder
addr : XAD
phon : XTN
1
Person
birth_dttm : DTM
gender_cd : CNE
1
is_a_role_of
marital_status_cd : CNE
primary_name_representation_cd : CNE
takes_on_role_of
0..1
primary_name_type_cd : CNE
primary_prsnm : PN
race_cd : CNE
Patient
ambulatory_status_cd : ID
birth_order_number : NM
living_arrangement_cd : ID
living_dependency_cd : ID
multiple_birth_ind : ID
newborn_baby_ind : ID
organ_donor_ind : ID
preferred_pharmacy_id : IID
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
Using Messages to Transport Documents
 HIMSS Message Creation
 Use a PRA LevelOne H&P document to create a Lab
Order message
 Use header information for the message.
 Base 64 encode the LevelOne document and include in
the message.
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
 Technique
 Architectural transformation is not possible as the
structures of the message and the LevelOne document
are not similar.
 Create a DOM of the LevelOne document and a DOM
of a message template.
 Walk the LevelOne DOM to find the information.
 Walk the message DOM to insert the information.
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
DOM - Document Object Model
An XML document can be represented as a tree of
nodes.
The DOM is a platform and language-neutral
interface for application programs in terms of a
standard set of objects to create, access, and
manipulate internal structures of XML documents.
APIs are defined for OMG IDL, and Java.
Examples:
• getChildNodes()
• getParentNode()
• getElementsByTagName()
We used IBM’s ‘XML for Java’ parser which
includes an implementation of the DOM interfaces.
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
H&P to Lab Order Mapping
Go to Word doc
HIMSSMapping.doc
Overview
Theory
Practice
Implement
Provider
HIMSS
Map
Issues
PRA Implementation exercise


See sample H&P
Map sample H&P to PRA LevelOne
– header
– body


Transform to architectural instance
Display with XSL stylesheet
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Issues in Implementation





Limits of architectural transformations
Available tools & technology
Header issues
RIM mapping
Other future KEG issues
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Creating PRA Documents using
an Architectural Forms
Processing Engine




Document-centric vs. non-documentcentric model
Managing expectations
Additional processing required
Mapping mechanism between client and
architectural DTD
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Document-centric model


assumes that all needed data is in
single document instance itself
includes document metadata prescribed
by the PRA Header
– document creation date; sign date
– document creator; physician id; facility id


example H & P follows this model
lends itself better to AF processing, but
problems do exist
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Non Document-centric model


core data is in the document(s) itself,
but other data lives outside of the
document
PRA header data
– document creation date; sign date
– document creator; physician id; facility id

coding data
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Managing Expectations

AF processing does not propose to:
– provide an API to external processes for
incorporating ancillary system data
– provide an API to the XML document itself
for the addition of doctype declarations,
stylesheet references, etc.
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Managing Expectations

AF does propose to:
– offer a solution for providing different
interfaces (each defined by a DTD) to one
XML document instance or type
– provide a simple, declarative syntax for
defining the transformation (i.e., casting)
rules for creating and accessing the
different interfaces
– provide an AF processing engine to
convert a client document to its
architectural instance(s)
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Limitations of AF for
Transformations



optimized for simple, one-to-one mappings
between client and architectural DTDs
– PhysicalExam ==> Section
possible, but tricky, to manage some one-tomany mappings
– Paragraph ==> Sentence + Sentence +
Sentence
– doesn't always have desired effects
not possible to re-arrange data in the
document hierarchy
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Final Thoughts

use architectural forms if situation is
right
– provides for easy transformations when
requirements are non-complex
– provides a quick and dirty development
tool for rapid prototyping
– with an appropriate API, could be used to
do some significant part of a transformation
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Final Final Thoughts


use more powerful declarative
language, such as XSL-T, (with the
added capability to interact with
processes external to the document, if
possible) when possible
create a custom transformation software
module using an API to the document,
such as the DOM or the SAX
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
PRA Header :: MIM -> MOD -> HMD -> DTD
(Other Message
Object Diagrams)
Message
Information Model
Per son
bir th_dt tm :
bir thpl a
TS
ce_nm :
deceased_dt tm :
ST
educat
TS
i on_l e
vel
gender_cd:
_cd
IS
m
ar it al_stat us_cd
: IS
pr
i mar y_
pr snm :
re
cig
e_cd
: i lf iati on_cd
rXPN
la
io
us_af
IS
: IS
0.. 1
1 part icipat es_
as
si _t he
_pr im ary_provide
0.. *
r_
f or
is_pari ci
t pa
nt _
Encount er_prforacti ti oner
part icipat ion_type
_cd
1
t kes_on_rol e
a
_of
si _a_r o
l e_
of 0.. 1
Pat ient
ambul a
t ory_stat us_c
cl
d
:Mn
IS
ssi
f icat
on
_cdent
: _cd
liCa
vi
g_ar
r iangem
li: vi
ISng_depe
ndency_cd
: IS
m
ul tibor
l e_bi
p
r th_ind
new
n_baby_i
nd:
ID
: IgD
or
an_donor_i nd
tr: ia
ISge_classif icati on
_cd
Indi vidual _healt hca
r e_pr ac
t it i one
r
posit ion_
pract it ioner_t ype
cd
pri mar y_
_cd
car e_i
0.. 1nd
re
si den
cy_f ield
_cd
is_a_r o
l e_
of
takes_on_rol e
_of
1
0.. *
has_a_
pr im ary_pro
vider
si _invol ved_
in
1
1.. * is_associated_
wi th
has_as_par ti cip
1
ant
Pat ient _
encount er
encoun
t er_cl a
ssii cat
f ion_c
d
end_dt
:
I
S
t
m
:
expected_insurance_plan_qt
TS
i volve iyf rs: tN_s
n
Mi mi lar_i lness_dt
s
: DT
id
:i ent_classif icati o
pat
n_c
1.. * CX
da
st
: rI t_
Sdt t
stat us_cd :
m
IS
Hierarchical
Message Definitions
Message Object
Diagram
Message
Message
Informatio
Structures
Elements Message
Model
n
C
D
Informatio
Mapping Message
Structures
Elements
Model
n
C
D
Mapping
1r oot
1 r oot
Pat ient _
encount er
Pat ient _
encount er
M
1
M
stat us
_cd
1 CE
stat us_cd
26
M
1
M
1
encoun
t er_cl a
ssii cat
f ion_cd
1 CE
encoun
t er_cl a
ssii cat
f io2
n_cd 12
M
1
M
1
id1
1EN
ST
C
1
id
3 M
1
M
M1
1
M
1
1 st
VTS
at us_cd
1
end_dtt m
26
R
M1
1
R
1
R
1
M
1
R
1
R
1
M
1
R1
R
1
R
1
M
1
1
1
ENC
1
ENC
ENC
1
1
stat us_cd
end_dt
1 CE
tm
4 M
1
encoun
t er_cl a
ssii cat
f ion_cd
expected_insurance_plan_qt
expected_insurance_plan_qty 1 NM
5
1 CE
encoun
t er_cl a
ssii cat
f ion_cd
2
y12
M
1
id
end_dtt m
fi rst _simi lar_i lness_dt
1 ST
pati ent_classif icati o
n_cd
1r VTS
sta
t_dt tm
1 VTS
id
1 CE
end_dtt m
1 VTS
3
4
fi rst _simi lar_i lness_dt 6
M
3
1
pati ent_classif icati o
n_cd
7
13
3
1
star t_dt tm
8 R
4
R
3
M
1
1
expected_insurance_plan_qty 1 NM
y
expected_insurance_plan_qt
5
R
1
R
1
fi rst _simi lar_i lness_dt
1 VTS
fi rst _simi lar_i lness_dt 6
R
1
R
1
pati ent_classif icati o
n_cd
1 CE
pati ent_classif icati o
n_cd7
R
1
R
1
star t_dt tm
1 VTS
star t_dt tm
M
1
M
1
8
13
4
3
1
PRA Header :: Future Directions :: MIM
PRA Header :: Future Directions :: MOD
PRA Header :: Future Directions :: HMD
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
LevelTwo :: Coded Sections*
<section identifier="10203-8" preferred.name="PHYSICAL FINDINGS"
name.of.coding.system="LN">
<section.title>ADMITTING PHYSICAL EXAMINATION</section.title>
<section identifier="8716-3" preferred.name="VITAL SIGNS"
name.of.coding.system="LN">
<section.title>GENERAL</section.title>
<paragraph> The blood pressure is 170 / 88, pulse 80 and regular, and
respirations 18. She weighs 240 pounds. </paragraph>
</section>
<section>
<section.title>HEENT</section.title>
<section identifier="10199-8" preferred.name="HEAD"
name.of.coding.system="LN">
<paragraph>Examination of the head is normocephalic. </paragraph>
</section>
<section identifier="1142-1" preferred.name="NECK"
name.of.coding.system="LN">
<paragraph> The patient has bilateral carotid bruit. There is no jugular
venous distention or lymphadenopathy. </paragraph>
</section>
</section>
</section>
*This example has not been reviewed by the KEG or the SGML/XML SIG, and is
intended to show that it can be done, and not how it should be done.
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
LevelThree :: RIM Mapping
<LevelThree>
<header>...</header>
<body>
Service_reason
Master_service
1
is_instantiated_as
•determination_dttm
•documentation_dttm
•reason_txt
• ...
•challenge_information_txt
•service_desc
•universal_service_id
0..*
delivers
1
is_delivered_during
0..*
is_reason_for
Service_event
0..1
has_as_reason
0..*
is_an_instance_of
•…
•begin_dttm
•end_dttm
•filler_id
•filler_order_status_cd
•service_desc
Service_intent_or_order
• ...
•expected_performance_time_qty
•order_id
Assessment
Observation_intent_or_order
•patient_hazard_code
•reason_for_study_cd
•relevant_clinical_information_txt
•reporting_priority_cd
•specimen_action_cd
</body>
</LevelThree>
Clinical_observation
•…
•abnormal_result_ind
•observation_value_txt
•references_range_text
•value_units_code
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
LevelThree :: RIM Mapping
"The content of a document can be represented with one or more observation segments." V2.3, Chap 9
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
LevelThree :: RIM Mapping*
<section>
<section.title>ADMITTING PHYSICAL EXAMINATION</section.title>
<section identifier="8716-3" preferred.name="PHYSICAL FINDINGS.VITAL SIGNS"
name.of.coding.system="LN">
<section.title>GENERAL</section.title>
<paragraph> The blood pressure is 170 / 88, pulse 80 and regular, and respirations
18. She weighs 240 pounds. </paragraph>
<RIM>
<Clinical_observation identifier="9279-1" preferred.name="RESPIRATORY
RATE" name.of.coding.system="LN">
<observation_value_txt>18</observation_value_txt>
<value_type_cd type="ST"/>
</Clinical_observation>
<Clinical_observation identifier="3141-9" preferred.name="BODY
WEIGHT" name.of.coding.system="LN">
<observation_value_txt>240</observation_value_txt>
<value_type_cd type="ST"/>
<value_units_cd units="pounds"/>
</Clinical_observation>
</RIM>
</section>
</section>
*This example has not been reviewed by the KEG or the SGML/XML SIG, and is
intended to show that it can be done, and not how it should be done.
Overview
LevelThree :: RIM Mapping*
Theory
Practice <section>
Implement
<section.title>HEENT</section.title>
Issues
<section identifier="1142-1" preferred.name="PHYSICAL FINDINGS:NECK"
name.of.coding.system="LN">
ArchTran
<paragraph>The patient has bilateral carotid bruit. There is no jugular venous
Tools
distention or lymphadenopathy. </paragraph>
Header/2
<RIM>
RIM
<Clinical_observation ID="OBS1" identifier="F-F5480"
Future
preferred.name="carotid bruit" name.of.coding.system="SN3"/>
<Clinical_observation ID="OBS2" identifier="G-A102"
preferred.name="bilateral" name.of.coding.system="SN3"/>
<Service_event_relationship has_as_source = "OBS1" has_as_target =
"OBS2">
<relationship_type_cd identifier = "G-C220" preferred.name = "with
laterality" name.of.coding.system = "SN3"/>
</Service_event_relationship>
<Clinical_observation identifier="DC-72130"
preferred.name="lymphadenopathy" name.of.coding.system="SN3">
<observation_value_txt identifier="G-A204" preferred.name="absent"
name.of.coding.system="SN3"/>
<value_type_cd type="CE"/>
</Clinical_observation>
</RIM>
</section>
*This example has not been reviewed by the KEG or the SGML/XML SIG, and is
</section>
intended to show that it can be done, and not how it should be done.
Overview
Theory
Practice
Implement
Issues
ArchTran
Tools
Header/2
RIM
Future
Future KEG/PRA Issues






Header derivation
Goals for L2, L3
RIM mapping
Tables
non-XML data
??