InheritableInformation Interchange

Architectures

Steven R. Newcomb

srn@techno.com

HIMSS 2000, Dallas, Texas USA, 9 April 2000

2

Healthcare information interchange

Healthcare providers do not compete by making patient records, insurance forms, etc. inscrutable to their competitors.

The Healthcare industry must be able to purchase information systems from competing suppliers, and still have reliable information interchange.

3

Healthcare information interchange

For any given type of healthcare document,

any software designed for that type of document must be able to

read,

create, and/or

edit

any instance of that type of document, no matter what other software (written for that same type of document) will read or edit it later.

4

Therefore...

All healthcare information must conform to standard models of structure (“syntax”) and meaning (“semantics”).

If there is no agreed-upon model for the healthcare industry, the entire industry will have to buy all its software from a single vendor.

5

The software vendor’s dream

“Own” the healthcare industry.

Be uniquely indispensable in every transaction. Keep competitors out; put inscrutable proprietary

magic into the information. Keep industry ignorant of its ability to take

control of its own evolution.

6

The healthcare industry is not stupid

Yes, but foolish greedy software vendors believe they must own everything.

Healthcare costs well over $1 trillion annually, 40% of which is said to be paper management.

Computerization of healthcare would be worth owning!

7

How to take control

Accept continuing responsibility for the structure and meaning of all healthcare information.

Understand and apply the international standard languages of power:

Document type definitions (DTDs) (for syntax) Property sets (for semantics).

Demand vendor conformance!

8

DTDs describe standard languages

Standardization of the language of business messages is essential for communication to occur.

XML is a language-language. It provides a way for many kinds of messages, using many different “languages” (vocabularies), to be understood (“parsed”) by a single standard piece of

software called a XML parser.

Validating XML parsers can verify that a message conforms to the syntax of an industry's business language.

9

Why have industry-wide DTDs?

A DTD represents a contract between information providers, information users and information processing system vendors.

It’s a model that users agree serves their needs.

So, creating an industry-wide DTD that formally expresses the business language used in any given message type is the most essential step to be undertaken by any industry in its effort to exploit the power of XML.

10

Why an industry DTD/Schema will not work

DTDs/Schemas are static, while business changes constantly.

DTDs/Schemas are monolithic, while business models vary widely.

The fundamental function of a DTD: …to make the form and substance of business

messages predictable and understandable...

...is at odds with the realities of incessant change and increasing diversity and specialization.

11

What is the answer ?

How can we detect the need for change in the DTD/Schema?

How can we permit individual businesses to deviate from the industry-wide DTD/Schema freely?

It turns out both problems are solved by the practice of allowing syntactic and semantic constraints of business languages (“base architectures”) to be inherited, rather than precisely monolithically adhered to.

12

The KONA (HL7) Architecture

The KONA group was among the very first to recognize the value of the inheritable architectures paradigm.

The paradigm solves the problem of making patient records both flexible and reliably interchangeable, even between research hospitals and rural clinics.

13

Standardization has practical limits

An industry-standardizing schema can't change much, or the benefit of having a standard is lost.

But business changes constantly, and every business is necessarily different from every other.

One size never fits all (and often doesn't fit anybody).

14

Inheritable DTDs/Schemas ("meta-DTDs")

Look like any other DTD or Schema. What makes them different is how they're used.

Are used to define the structure of information interchanged throughout the community.

They don't define everything you're allowed to interchange; they only define what the entire community agrees must be interchangeable. Individuals can specialize them. Inheritable DTDs distribute control of structure

without interfering with information interchange.

15

Inheritable DTDs/Schemas ("meta-DTDs")

It's an ISO/IEC international standard (ISO/IEC 10744:1997 Annex A.3).

It’s not a standard that software vendors like to support; it makes industries like healthcare much harder to “own”. But that doesn’t matter because all the necessary

software is already free.

The W3C currently doesn't understand inheritable DTDs/Schemas, and it actively suppresses the whole concept.

16

Inheritable Architectures in Healthcare

Can have rigorously reliable information interchange and member control of product/service development. Control over different document types can be horizontally

distributed. Control over a document type can be vertically

distributed.

All the players in the healthcare industry can create, interchange, edit, interpret and annotate(!) all components of healthcare documents.

17

Inheritable Architectures in Healthcare

Every kind of information can be validated against a model for that kind of information; non-conforming software can be identified quickly and unambiguously.

Multiple software vendors can compete. Healthcare companies can choose from among them, and they can even build their own systems without compromising information interchange.

18

Inheritable Architectures in Healthcare

Enterprises and sets of business partners can enhance the industry-wide DTDs in arbitrary ways without compromising information interchange or validation.

Any number of subordinate specialized "standards" can conform to the industry-wide standard.

Business-partner conventions can be merged.

19

Inheritable architectures are about…

Using constructs with predefined semantics as templates for specific element types

Reusing software components that are built for defined architectures

Inheriting semantics from more than one architecture at a time

Accommodating diverse user groups while maintaining control at a general policy level

20

The Value of Inheritable Architectures

Inheritable architectures allow user groups to:

Agree on common functionality while not abandoning group-specific semantics

Use their own terminology Integrate architectural elements with group-

specific elements (or use multiple architectures) separably, but in a single source document.

Use standardized architectural engine software

21

Multiple inheritance

An XML instance can conform to multiple DTDs without having to duplicate the same data content.

A single element can seen in terms of several architectural forms, one from each of the inherited DTDs/Schemas.

Everything needed to convert the information to the industry-wide DTD is already inherent in the XML instance.

22

Recursive or “nested” inheritance

An architectural instance, after it has been extracted, may itself have one or more base architectures.

Thus, an architectural instance can be extracted from an architectural instance.

This allows enormous flexibility, on account of the fact that there is no limit on the number of recursions.

23

Demonstration

A demonstration of architectural inheritance.

Only free, open-source, industrial-strength software is being demonstrated here.

The software being demonstrated is James Clark's industry-standard "SP" parser. A link to the “sx” application is available at http://www.hytime.org/htnews.html.

24

Overview – Mortgage Bankers' Architecture

25

Levels of Mortgage Bankers' Architecture

The top (most fundamental, "global") level consists of things that are used in multiple parts of the MBA architecture, e.g., person, company, postal address, etc. These provide consistency to all parts of the whole architecture.

For the healthcare industry, the top layer might be very similar: a DTD for personal contact information, a DTD for organizational contact information, common ways of expressing quantities and other very basic, uncontroversial things.

26

Levels of Mortgage Bankers’ Architecture

The second level consists of "core" DTDs, each of which corresponds to a kind of information that might be found in a loan casefile, e.g., subject real estate property, borrower, etc. Each is maintained by MBA members who are expert in the corresponding knowledge domain.

In healthcare, the second level of DTDs might include prescriptions, laboratory results, medical imaging, insurance, annotations, physician communication, policies & procedures, utilization rules, etc.

27

Levels of Mortgage Bankers' Architecture

The second level also includes process-oriented DTDs. These include credit reporting, underwriting, etc.

In healthcare, process-oriented DTDs might include managed care support, medical technology training, continuing education, regulatory matters, patient services, coding, credentialing, clinical scheduling, etc.

28

Levels of Mortgage Bankers' Architecture

The third level is the "Union DTD", the base DTD that comprehensively inherits the "core" architectures. All MBA architecture users use the Union DTD as their base architecture (whether they know it or not).

The Union DTD may be very large, but it need not be daunting. Users only know the parts that are relevant to them.

29

Levels of Mortgage Bankers' Architecture

The fourth level consists of vendor-specific enhancements to the Union DTD. Individual members and their business partners absolutely control this layer. They do not ask permission to make such enhancements. The base architectures do not change as a result of these enhancements.

In healthcare, such enhancements might be made by specific insurers or HMOs, research hospitals, clinical practices, universities, government agencies, physician’s networks, etc.

30

Finally...

Openness, tolerance of diversity, and community-wide access to the evolutionary process are vital for successful information interchange.

The ISO inheritable architectures paradigm allows the evolutionary process of designing interchangeable information to be managed in a consensus-building, reality-driven, unconstrained fashion.

31

References - Inheritable info architectures

A slide presentation on architectural forms in XML: http://www.hytime.org/papers/srnXTech99/

A white paper on architectural forms in XML: http://www.isogen.com/papers/archintro.html

The ISO standard itself: http://www.ornl.gov/sgml/wg8/document/n1920/html/clause-A.3.html

The “sx” application of the SP parser, with support for inheritable architectures in XML (for Linux, Solaris, and Windows): ftp://www.techno.com/TechnoTeacher/SPt

32

A Word From Our Sponsor...

ELF Solutions, Inc.

Booth 1525

+1 800 327 0545

http://www.elfsolutions.com