The Kona Proposal for Electronic Health Care Records


The week of July 7, 1997 a group of physicians, healthcare system vendors, and consultants met at Kona Mansion on Lake Winnipesaukee New Hampshire.

The outcome of that effort is the Kona Proposal which defines a multi-level architecture for the exchange of Electronic Health Care Records.

This proposal does not represent the opinion of any other individual, corporation, or organization. Explicitly, this is a suggestion being put before the HL7 SGML SIG and as such has no more standing as an official document of the SIG than any item brought to the group for discussion.

HL7 - Health Level 7, an ANSI-recognized standards writing organization for Medical Informatics. HL7 also refers to the messaging syntax created by the organization.

This presentation is a subset of the information located at

The mailing list - To subscribe send ‘subscribe sgml-hl7’ to


Sponsors and Participants





Kurzweil Applied Intelligence

Rachael Sokolowski


Oceania Incorporated

Michael Toback


Oceania Incorporated

Jason Williams


Sequoia Software Corporation

Ron Capwell


Sequoia Software Corporation

Jasen Fici


Sequoia Software Corporation

Anil Sethi


Kaiser Permanente, Southern California

Bob Dolin

Robert H.


LAC+USC Medical Center

Dan Essin


Pathology Medical Group

John Spinosa


The Word Electric

Liora Alschuler


Information Assembly Automation Inc.

Lloyd Harding


Isogen Consulting

Eliot Kimber






Problem Statement

The growth of managed care and the business of health care is placing more pressure on medical professionals to maintain medical information in electronic form to facilitate exchange between the constituencies including caregivers, managers, insurers, regulators, researchers, and the courts.

Current standards for exchange of information between clinical systems cover messaging of fielded data, but do not meet the need for reliable exchange and semantic processing of hierarchical, structured, clinical narrative. A comprehensive healthcare information exchange standard must include this narrative and the full electronic health record.

Two major forces must be resolved in any solution to the problem:

  1. The diverse processing/markup needs of the constituents.
  2. The multifaceted, and changing semantics of medical knowledge.



Constituent Needs

Each constituent has unique requirements for the markup and processing the clinical narrative:



Medical Content

The multifaceted, and changing semantics of medical knowledge includes:




Medical Definitions

Before proceeding with the problem solution the following definitions were agreed to:


An Electronic Health Record is a set of attested SGML documents. There is no requirement for completeness. A patient may for personal reasons see more than one physician and thus have more than one EHR. However all entries in an EHR are attested indicating by whom and when each piece of information was validated. This is important for the next health care provider so they may confidently use past information when providing care.

A view is not attested and may change over time. Since a summary or extraction of information may lose or mis-interpret subtle narrative cues any change to an attested record is by definition no longer an attested record.

Thus if the health care provider uses a HRV to formulate a diagnosis the health care provider takes full responsibility for any legal claims.



Solution Summary

Total agreement on content and information within a domain as large as Medical Informatics is not feasible.

The Kona Architecture does not envision or advocate a single prescription for the electronic health record or for associated documents such as claims forms and summaries.

The Kona Architecture provides multiple levels that differ in their degree of structural and semantic specificity to reflect the community of constituents for which they are intended.

The Architecture sets up conventions that allow exchange partners to agree on content without waiting for the action of a standards body and without upgrading technical capability.



The Kona Architecture

The working assumption is that exchange standards such as this architecture cannot and should not control document schemas.

The Kona Architecture is a multi-level SGML architecture. This meta-schema definition creates a framework within which individual schemas can conform at various levels of exchange.

Architectural Forms are used to map highly defined structures to lower levels of the architecture.

The exact definition of the most useful degrees of specificity will be developed over time within an open standards environment.

Specification of the architecture does not obviate the need for DTD design to meet the needs of individual organizations and constituencies at each level of the architecture. In other words, the exchange architecture and specific declaration sets (DTDs) within the architecture are not intended to be "authoring" DTDs or templates suitable for collecting and entering information. The exact requirements for exchange will always be, and should remain, a matter of policy between exchange partners.

New documents will require a definition of the document content and expression of that content in a Kona-compliant document


Conformance and Compliance


Is defined as the adherence to the syntactic requirements of a level of the architecture expressed in the declarations (DTD) for that level (a conformant document is a valid SGML document).

Exchange partners can declare conformance to higher or lower levels of the architecture by declaring that a DTD derives from a certain level of the architecture. Conformance can be validated by an SGML parser.


Is defined as conformance to a level of the architecture AND to specific policies on document content.

Exchange partners can declare compliance to a level of the architecture by conforming with that level and with content agreed upon as a matter of policy between the exchange partners.

For example, an insurer can require conformance with the ClinicalContent level of the architecture. The insurer can require compliance by setting a policy that specifies the billing, diagnostic, and treatment codes that must be identified within the document.

Thus compliance is a policy that can be met and expressed in the applicable Kona-conformant schema. Institutions can set information requirements as a matter of policy without amendment to the exchange standard or upgrades to the technical infrastructure of either party.




The Kona Architecture






Level 1 - ProseDoc

The architecture across all levels derive from this level.


Markup is minimal covering basic underlying language constructs (Prose) and embedding of image, audio, and non-textual material.

Communities of Interest:

The widest possible community within healthcare with an interest in exchanging information. Example: Exchange of imaged documents or unstructured, character-based documents.


This level allows users of higher level systems to incorporate images from and exchange records with document management-oriented medical records systems.



ProseDoc Visual




Level 2 - ClinicalContent

The second level is called ClinicalContent and applies to all documents used for clinical care.

This level requires loose agreement on content and structure such as that which would apply across institutional boundaries but within an interest group such as all insurers.


Requires minimal mark-up of the content and provides markup for fundamental semantic types (SOAP - subjective, objective, assessment, plan) used in clinical documents.

Communities of Interest:

Healthcare insurance carriers, government regulatory agencies, and broad national constituencies with minimal specification of common data requirements. All parties with any level of structured markup exchange requirements. Further utility is possible at this level, but that must be set by policy decision.


Healthcare providers interested in data for the treatment of patients probably would find much (if not all) treatment data at this level.

Likewise, interchangeable insurance data may be provided at this level. Along with patient treatment data, this level can accommodate policies that specify the data required for insurance claims processing. Many Practice Management and Billing System vendors may elect level 2 compliance.



ClinicalContent Visual







Level 3 - EHR

The third level is called Electronic Health Record (EHR) and is intended to meet the requirements of those creating, managing, and processing EHRs.

This level has not been defined. We encourage the SGML-HL7 SIG to develop reference level 3 DTDs.


Requires markup and semantics from many components of the HL7 standard, including the Reference Information Model (RIM), the current Chapter 7 document classifications, and others sources yet to be determined.

Communities of Interest:

Those who wish to exchange electronic health records. Example: Transfer of patients information in an outpatient setting for admission to a hospital.


Clearly, many Electronic Health Record systems capture data at this level of granularity. Traditionally, these systems store codified data in some persistent data store (i.e. RDBMS or OO storage). These systems, then, may exchange data by exporting out from their internal representations into a Kona level 3 or higher SGML document(s). This exchange would be valuable in the transfer of medical records between systems and locations.



Level 4

The fourth level is called Enterprise and should meet the requirements of a tightly bound community of interest.

This level has not been defined. We encourage the SGML-HL7 SIG to develop reference level 4 DTDs.


Requires additional, site-specific or enterprise-specific SGML mark-up. It addresses a granularity of data traditionally reserved for use in specific domains, outside the general interest of healthcare. These systems store and manipulate very specific data elements for use within the enterprise.


Communities of Interest:

A tight community of interest within an enterprise such as an integrated health system or independent practice association.




Summary of Applications

After agreeing to the architecture we spent Thursday testing the design by implementing the following sample applications.




Our focus during the week was to create a proposal that would lay the groundwork for the exchange of EHRs.

We use Architectural Forms within the Kona Architecture to provide multiple levels of conformance while allowing exchange at any level.

However, we recognize XML is an important piece of the future and would like to ensure that EHRs can be exchanged via XML. This proposal is congruent with the emerging XML standard in several ways:




The Future

Much work still needs to be done including:


As with all standardization efforts volunteers are welcome and appreciated. Medical Informatics is a large domain that has had little input for the SGML and HyTime communities. We welcome all interested parties to participate both in promoting the Kona Proposal within the HL7 framework and throughout the international medical community.

Not only does this provide an opportunity for our community to further our vision but is a wonderful opportunity to make a positive impact on our health care systems.