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.

The mailing list - sgml-hl7@list.mcis.duke.edu. To subscribe send ‘subscribe sgml-hl7’ to majordemo@list.mcis.duke.edu.

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.
1. The multifaceted, and changing semantics of medical knowledge.

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

• The single physicians patient load and small office requirements demand low cost of entry, little change in their day to day processing, and improvement in their ability to provide care.
• The larger managed care providers, hospitals, etc. require data interchange between cooperating health care professionals, process management, and administration.
• Insurers and regulators require mapping standardized codes and semantics to permit assignment of benefits and adhere to regulations.
• Research organizations needs include the ability to analyze the clinical experience for trends and patterns. Hopefully for the improvement of medical knowledge.
• The courts require the ability to determine the trail of responsibility.

The multifaceted, and changing semantics of medical knowledge includes:

• Each medical specialty and health care provider department utilizes specialized language and codes (ICD9,CPT,SNOMED,UMLS...).
• The content may include output from many different tools and techniques, images, forms, etc.
• Medical knowledge is constantly growing and changing. As tools and techniques advance our medical knowledge, new generalizations may merge previous concepts and nomenclature. Better discrimination may segment and create branches to knowledge once considered unitary.

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

• Entry - An entry is an attested SGML document.
• Attestation - Includes a date, time, signature, and staff ID number
• Health Record - Multiple entries for one individual
• EHR - Electronic Health Record - an electronic version of a Health record

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.

• • HRV - Health Record View - Summary or extraction from entries.

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.

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.

• Allows amendment or extension of the exchange standard to include new data or narrative or new combinations of data and narrative.
• • Allows partners to identify and encode highly granular (atomic) concepts such as billing codes or controlled vocabulary terms at all levels

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

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

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

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

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.

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

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.

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.

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.

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

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

• Kurzweil Applied Intelligence, Inc. took non-Kona SGML patient records created in their voice-enabled structured reporting system and transformed the records into Kona-compliant SGML using James Clark’s NSGMLS.
• Oceania Inc. can generate SGML from their EHR system. Working with Dr. Bob Dolin of Kaiser Permanente, they transformed the generated SGML to conform to a new, Kona-compliant DTD.
• Dr. Daniel Essin, LAC+USC, created a document directly from the ProseDoc meta-DTD, then created an obstetric preanesthetic (OBA) DTD and SGML document and mapped those to the ClinicalContent Kona architecture.
• Dr. John Spinosa of Pathology Medical Group created a surgical pathology DTD, mapped it to the Kona architecture, and then created a set of five compliant reports. These he translated into HTML using mappings to the first and second levels of the architecture.
• Sequoia Software imported Kona-compliant files from each of the four front-end applications to create a repository from which they could extract individual entries and "patient records". The documents were indexed, searched, retrieved, converted to HTML using a single DSSSL style sheet, and displayed on the Sequoia Databank client which is a web browser.

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:

• Users can exchange Kona SGML documents without sending a DTD because they can validate the document against the architecture.

• Users can translate Kona documents into XML for distribution and browsing.
• Users can create documents in XML editors to be transformed into Kona-compliant SGML in a hands-off process. This transformation should be no more demanding than that which we have demonstrated for non-Kona SGML and proprietary format documents.

Much work still needs to be done including:

• Incorporation into HL7
• Development of DTDs for the diverse specialties within health care
• Promoting of Electronic Health Records throughout the medical community

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.