The Kona Proposal
[Archive copy mirrored from: http://www.mcis.duke.edu/standards/HL7/committees/sgml/kona.htm, 970718]
The Kona Proposal describes a method in which electronic healthcare records (EHR) can be created, exchanged, and processed using SGML, Standard Generalized Markup Language, ISO 8879:1986.
The project of bringing participants together to review this problem was called Operation Jumpstart and the result is the Kona Proposal. Operation Jumpstart has no further role in the enhancement and development of this Proposal. Further work on this proposal is the province of open standards bodies, specifically the HL7 SGML SIG, if it chooses to do so.
The individuals who participated in Operation Jumpstart invite and encourage all interested parties to become active in the HL7 SGML SIG to which we have given the copyright to this Kona Proposal and to all of the documents, files, and scripts associated with it. The next meeting of the SIG is the week of August 18-22 in San Francisco. See http://www.mcis.duke.edu/standards/HL7/hl7.htm or call 313/677-7777 for more information. For information on the HL7 SGML Mixer cosponsored by the HL7 SGML SIG, The Graphic Communication Association, and SGML Open, see http://www.gca.org/conf/newitcon/mixer.htm.
This proposal is an expression of the group that met at Kona Mansion on Lake Winnipesaukee New Hampshire the week of July 7, 1997, and 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.
The Kona Architecture is a new approach to exchange of electronic health records and documents.
Exchange requires a prior agreement on content and information definitions. However, total agreement within a domain as large as Medical Informatics is not feasible. Using SGML, the metalanguage from which HTML was created and on which XML, the new standard for Web documents, is based, the Kona Architecture resolves these two opposing forces by establishing scaleable levels of exchange so that partners can determine the degree of conformity in the documents they send one another. The architecture:
The levels differ in their degree of structural and semantic specificity and in the scale of the community for which they are intended. The lowest level of the architecture requires no structural definition beyond the header and can be satisfied with imaged data. The highest level requires structural and semantic specificity, such as might exist within a single enterprise or within a tightly bound professional community.
This proposal does not envision or advocate a single prescription for the electronic health record or for associated documents such as claims forms and summaries. Instead, this proposal 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. Thus, if adopted, an insurer will be able to define a new submission form and require that providers submit these forms as Kona-compliant SGML documents without amendment to the exchange standard or upgrades to the technical infrastructure of either party. New documents will require a definition of the document content and expression of that content in a Kona-compliant document.
There may also be other documents that are part of the EHR, such as an aggregated view or report formatted and built as an SGML document for viewing, transport, archiving or other purposes. These SGML documents fall outside of the scope of the collection of attested documents which make up the patient health record. These documents have not been described in detail in this proposal, although provision is made for their inclusion.
At Kona Mansion, we demonstrated feasibility using diverse technology and a wide-ranging approach to document content.
After reaching consensus on our goals and designing the basic Kona Architecture, we produced over 30 documents covering patient encounters and pathology reports using several different DTDs and several systems for document creation: two specialized EHR systems, several SGML editors, and one ASCII editor. Some documents were created from alternate forms of SGML (non-Kona-compliant), some from proprietary data formats, some from paper legacy documents, and some as native, Kona SGML.
We imported the Kona-compliant documents from these diverse systems into one document repository. We queried the repository across all documents according to indexed markup and text-in-context. The repository assembled an electronic health record composed of multiple encounters, each with multiple entries (documents) generated by different EHR systems and different Kona-compliant DTDs. A single script translated the SGML documents into HTML.
The role of any exchange standard is to enable a flow of information (equivalent or better than that which exists in the paper world) without constraining the technology or the content on either end of the exchange. An exchange standard should render technical requirements transparent to exchange policy. In other words, policy changes that affect the content of an exchange should not require changes in the standards and technology that supports that exchange.
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. The constituencies for such a standard include caregivers, managers, insurers, regulators, researchers, and the courts. Everyone wants maximum data flow without loss or constraint.
This Kona Proposal is intended to:
The Kona Proposal embodies the Mission and Design Principles of the HL7 SGML SIG by making no assumptions about application processing which explicitly proscribes imposition of local application processing requirements.
Portions of the HL7 2.x specification (and the parts of Version 3 that are equivalent in scope) express information that is useful and required in the clinical content of the EHR. This information has been expressed in SGML syntax and incorporated into the Kona Proposal. The object modeling of the RIM presents an additional area of information that may be added to the Kona Architecture as it is extended and filled out.
In several areas, we have applied the data models of HL7 2.x message syntax and the Reference Information Model (RIM). A full standard based on this architecture would integrate all relevant portions of existing and future HL7 data models. (Portions of the data model do not pertain to clinical content and fall outside the scope of this proposal.)
The HL7 V.2.x syntax is a messaging syntax. The scope of the Kona architecture is not messaging, but persistent clinical content and as such, can stand on its own independent of an HL7 message. The Kona Proposal describes an SGML architecture which allows exchange of health records either independently or within an HL7 version 2.x message segment.
Thus, an entry transmitted within an HL7 message would contain information in its header that is redundant with the HL7 message "wrapper". An entry exchanged without an HL7 message would include header information derived from HL7. We call this the "inside-outside" model of SGML and HL7 messaging.
The Kona Proposal lays the groundwork for a standard document architecture for healthcare. Conformance with the architecture can be validated, but the architecture itself does not define the content of healthcare documents. To some extent, existing HL7 standards already define clinical content (e.g., section headers for various documents are included in HL7 V2.x). As the work of other committees and SIGs progresses, as concensus is reached on industry-wide forms of clinical content, this model can be expressed in the Kona architecture. Furthermore, it is our hope that, should this approach to document architecture be embraced by HL7, the HL7 Technical Committees and Special Interest Groups of HL7 will extend the document architecture into their domains.
| SGML | Standard Generalized Markup Language, ISO 8879:1986 |
| HL7 | Health Level 7, an ANSI-recognized standards writing organization; HL7 also refers to the messaging syntax created by the organization. |
| EHR | Electronic Health Record - an electronic version of a Health record |
| Health Record | Multiple entries for one individual |
| Entry | An entry is an attested SGML document. |
| Attestation | Includes a date, time, signature, and staff ID number |
| Health Record View | Summary or extraction from entries. A view is not attested and may change over time. |
| Document | SGML document which consists of the document element and the prolog |
| Schema | A declaration set, documentation of the schema, and optional supporting specifications such as style sheets and supporting processes such as transforms or standard queries. |
| DTD | SGML Document Type Definition; a schema for a single document (more than one document can use the same DTD). |
| SGML Architecture | A schema for a class of documents |
| Kona Architecture | The architecture described by this proposal. |
| Level of Architecture | Consistent degree of specialization represented in a set of one or more document architectures identified with a community of interest |
| ProseDoc | The lowest, least granular level in the Kona architecture |
| ClinicalContent | The second level of the Kona architecture. |
| Conformance | 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). (Usage and community of interest for each level of conformance is defined below.) |
| Compliance | 9;Conformance to a level of architecture and to specific policies on document content. For example, a community of interest can specify that compliance requires conformance with the Clinical Content level of the architecture and inclusion of markup for specified billing and diagnostic procedures. |
| Derivation | A conceptual and semantic expression of the relationship between schemas at different levels of specialization in an SGML architecture. |
The Kona Architecture is a multilevel SGML architecture. This meta-schema definition creates a framework within which individual schemas can conform at various levels of exchange. The exact definition of the most useful degrees of specificity will be developed over time within an open standards environment. The working assumption is that exchange standards such as this architecture cannot and should not control document schemas.
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.
To demonstrate the usage of HL7 data models, portions of the HL7 2.3 patient identification segment formed the basis of the patient information Clinical Content header.
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. Exchange partners can declare compliance to levels 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 which can be validated by an SGML parser. 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 changing technical specifications, thus making the technology transparent to policy-makers in the same manner as existed when information was exchanged on paper.
The Kona Architecture provides multiple levels of markup specificity and thus multiple levels of conformance options. All levels require an SGML header and all levels allow the insertion of domain specific taxonomies. Any party interested in utilizing this architecture can do so, at some level.
This section offers examples of how users may map into the levels of the architecture.
The architecture across all levels derives from this level, so documents at a higher may link to or store scanned images using markup defined at level 1. prosedoc.mtd is a reference, level 1 DTD.
The SGML header can link to other medical records stored outside of the SGML document and identify the document in a repository. 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 with an SGML header.
This level allows users of higher level systems to incorporate images from and exchange records with document management-oriented medical records systems.
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. clincont.mtd is a reference, level 2 DTD.
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. Example: Submission of records supporting an insurance claim where the insertion of billing and diagnostic codes is specified and required by the insurer.
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.
The third level is called Electronic Health Record (EHR) and is intended to meet the requirements of those creating, managing, and processing EHRs. 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. 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.
XML, eXtensible Markup Language, is a new standard proposed and sponsored by the W3C to make possible standard exchange of richly encoded documents on the World Wide Web. XML is a subset of SGML, simplified for use on the Internet. XML is widely supported and is expected to become a common feature of Web browsers and therefore of desktops and operating systems.
This proposal is congruent with the emerging XML standard in several ways:
Following, in no particular order, is a list of areas we did not address in this proposal. Doubtless more will surface in the future:
A great deal of thanks is due the sponsoring organizations:
|
Liora Alschuler |
liora@the-word-electric.com |
The Word Electric |
|
Ron Capwell |
ron@sequoiasw.cm |
Sequoia Software Corporation |
|
Bob Dolin |
Robert.H.Dolin@kp.org |
Kaiser Permanente, Southern California |
|
Dan Essin |
essin@hsc.usc.edu |
LAC+USC Medical Center |
|
Jasen Fici |
jasen@sequoiasw.com |
Sequoia Software Corporation |
|
Lloyd Harding |
lloyd@bonsai.infoauto.com |
Information Assembly Automation Inc. |
|
Eliot Kimber |
eliot@isogen.com |
Isogen Consulting |
|
Anil Sethi |
anil@sequoiasw.com |
Sequoia Software Corporation |
|
Rachael Sokolowski |
rachaels@kurzweil.com |
Kurzweil Applied Intelligence |
|
John Spinosa |
spinosaj@scripps.edu |
Pathology Medical Group |
|
Michael Toback |
mtoback@Oceania.com |
Oceania Incorporated |
|
Jason Williams |
jwilliams@oceania.com |
Oceania Incorporated |