NCVHS Subcommittee on Standards and Security

Hearings on Message format standards, 3/29/99

Notes from Mark Shafarman, OACIS Healthcare Systems


Also available:

notes in rich text format (rtf)

PowerPoint presentation


 

1. patient medical record information

paradigm for "comparability" discussion

Messaging/object method interfaces must have a common information model and a common vocabulary model (both standard) with standard vocabulary applied to the standard information model (e.g. HL7 templates).

Communicating applications/systems do not need identical structures/database/vocabularies if they can map unambiguously to the common (standard) information / vocabulary model

E.g. sys A <-maps to/from-> common communication structures/codes <-maps to/from -> sys B

In this discussion, "information model" assumes an object information model (e.g. the HL7 RIM expressed in UML )

This model supports the addition of new specializations of clinical data objects as needed.

For the support of a new instance of a given specialization, this model needs only the 'master file' entry for that instance to be created (e.g. in the HL7 RIM, a new lab test is added by addition of a new master file entry for the clinical observations specialization of the service event).

Thus instead of adding several new attributes to the model to satisfy new data requirements, we add a new instance of the corresponding specialization, or if needed, the appropriate new specialization.

The information received via such an interface can be re-used in many different patient care and research contexts, independent of the context in which it was obtained.

e.g. a blood pressure measurement from a clinical document can be graphed with a blood pressure measurement taken by a nurse in another location, and with blood pressure measurements taken by an automatic machine.

Define/describe PMRI (patient medical record information)

Any information needed by a clinician to care for a patient under his/her professional responsibility.

Also includes financial/insurance/related to what services, medications, procedures, treatments a clinician needs to order to care for a patient.

Excludes financial/admin information not contributing to patient care (e.g. payroll information details about staff).

Includes permissions based on credentials/license (and other factors relating directly and indirectly to the care of the patient: social/family/work/environmental).

Why is comparable PMRI required? degree of comparability; consequences of lack of comparability...

If PMRI is not comparable:

information can't be shared across systems and there is no interoperability.

can't build a complete EMR with information from multiple sites/systems.

There are two main levels of comparability:

low:

includes: plain text, documents at HL7 PRA level 1; images with no accompanying discrete information.

this level must be viewed by a human caregiver to be meaningful.

high:

agreement on structures and vocabulary both.

supports automated (real time) clinical decision support (knowledge base applications) and research (data warehouse applications).

if high level of comparability is not available, applications Clinical Decision Support systems cannot unambiguously use/share/re-use patient specific information.

Errors in PMRI:

if clinicians judge that PMRI is inaccurate, the consequences will be similar to those of an inaccurate paper record:

the care of the patient may be inadequate or dangerous to the patient.

tests and procedures will get repeated to ensure accuracy for clinical decisions.

 

2. What is the role of syntax in communicating comparable PMRI?

In general:

What's important is not the syntax itself, but the information and vocabulary models expressed in a particular syntax. If the syntax can support the most granular level of the information and vocabulary models, that is sufficient.

At OACIS, we currently use the HL7 version 2 syntax (which has remained unchanged for versions 2.1, 2.2, and 2.3) as our preferred PMRI messaging syntax.

We have not had any difficulties using this syntax to create interfaces to support our clinical data repository and workstation applications.

We also have experience using CORBA (although this is not precisely a messaging syntax, but a standard way of expressing object interface specifications) in our middleware layer.

Additionally our OACIS Gateway++ supports parsing and generating EDIFACT syntax.

As mentioned above, if the information content of a message (or object interface) is granular enough to map to the major concepts and vocabulary needs of HL7 2.x, we can map the information to standard HL7 structures and codes, and store the information in our clinical data repository in a highly re-usable form. With HL7 version 3, this mapping will be much more interoperable; require less negotiation; and support a variety of interfaces to knowledge applications.

This (the information and vocabulary content) is more important than judging strengths/weakness of various syntaxes: they are all adequate to the level of structure and vocabulary of current data available through clinical interfaces.

The OACIS strategy is to use our interface engine to convert from one syntax to another when that is needed.

If there are market requirements for another syntax, we will enable our product to do the necessary conversion.

As above, the interoperability depends not on the syntax, as long as the basic granularity constraints are supported, but on the information and vocabulary structures.

Are some syntaxes better/more complete than others?

A common misperception in the industry is that using a particular syntax gives one more interoperability. E.g.:

The CorbaMED specifications require extensive negotiations on a site-specific basis because they lack definition of a standard information and vocabulary models.

XML: HL7 Patient Record Architecture (PRA) documents at PRA-level one are not more interoperable than plain text documents with standard HL7-style headers (at the OBR level). PRA levels two and three are still in process of being defined. One can create a very detailed XML-tagging structure (a DTD) for a given document, but if the tags don't reference back to an information model, and standard vocabulary is not being used, there is no ability to re-use the information for clinical decision support without extensive human intervention (analysis and additional coding).

In terms of completeness, ASN.1 is more complete than XML, which is HL7's first candidate syntax for HL7 v 3. But ASN.1 is less widely implemented, and XML is very popular at this moment; and XML has lots of "off-the-shelf" tooling support for multiple platforms.

Is the private sector making satisfactory progress in implementing the best syntaxes for interoperability?

This is more accurately a market-share question. As long as a syntax is widely used and has adequate granularity to support the information models, one would do better to see what emerges, and not make one's strategy dependent on any given syntax.

It is not clear that a single syntax is best for all technologies. E.g. XML is character based; CORBA (OMG IDL) is an object-based and not usually referred to as a syntax at all.

Since technologies, especially object technologies, are evolving rapidly, any single choice may be out-of-date in a matter of months.

Note that HL7's strategy is to support multiple ways of transmitting clinical information for its version 3. These strategies will allow the creation of the most appropriate way to transmit information for each technology, and they are described, not as syntaxes, but as "implementation technology specifications" (ITS layers). The concept is that the information to be transmitted is described in an abstract, technology neutral way: but to transmit the information, one must choose a technology. HL7 is developing a methodology that will encourage the creation of the needed ITS layers for version 3. The first such layer will be XML based.

What role should the federal government take in this area?

I don't think there is a role beyond insisting that the various ITS layers support the necessary granularity of the information model. But the federal government could, for a given technology, specify the ITS to be used, as long as this was done with the understanding that this specification was independent of the information model and vocabulary standards that specify the information content.

It's likely that translations between ITS layers will be needed; and the healthcare interface engine vendors are adequately supplying this service.

3. What roles can models play in defining, communicating and ensuring the comparability of PMRI?

What models are available? (data, information or process)?

The most extensively researched model, and the one based on the widest practical experience, is the HL7 RIM (Reference Information Model)

How can these models improve the development and understanding of uniform patient medical record data standards?

OACIS experience: OACIS has almost a decade of using similar models as the basis of our clinical data repository. Key features are (also see 1. Paradigm, above):

object model

new clinical data functionality added by adding specializations, not attributes.

within each specialization, the ability to handle new instances is added by adding master-file instances (e.g. adding the ability to process new lab tests by adding the corresponding master files definitions).

ability to map local vocabularies for specialization instances into standard vocabularies.

hence the model is never "finished" but always extensible in consistent, implementable manner.

with this strategy, standard interfaces to clinical decision support and other knowledge applications can be created.

These key features are shared with the HL7 RIM.

With these key features, all clinical domain information can be supported in an interoperable fashion.

The current parallel with HL7 is the HL7 Clinical Templates Project, where standard vocabularies are integrated with standard information models. The prerequisites for this are both the information models and the standard vocabularies, and a constraint language that is capable of applying the appropriate vocabulary subsets to specialization instances of the information model.

What are the impediments to the development and use of such models?

Such models are part of the information infrastructure needed for healthcare clinical applications.

In general, there is little vendor incentive to develop infrastructure: the demand comes from the users/consumers of this information.

vendors that integrate data from many sources are an exception to this generalization.

standards make integration from multiple sources not only possible but cost-effective

such standards also create a 'level playing field' for knowledge applications, since all such applications are dependent on large amounts of clinical data from other sources.

Can the private sector address these impediments satisfactorily?

Current competition is for desktop applications rather than for comprehensive EMR infrastructure

But infrastructure standards are critical to decision support and knowledge applications

What role should the federal government play?

Support for HL7's work from private sector is helpful, but federal support in terms of standards-based requirements can also accelerate progress.

ex. CASIG: HL7 Claims Attachment SIG.

ex. CDC's Electronic Lab Reporting (ELR) project.

Suggest investigation of options for providing support to the evolution of the HL7 RIM.

Suggest support to creation of standard vocabularies that don't have license fee impediments to common use.

There is a critical need for the "base" level of patient clinical information to be transmitted using standardized codes at the level of granularity needed for clinical decision support (rather than at the lesser granularity of billing/reimbursement coding). This includes support for: problems/diagnoses, signs/symptoms, clinical ancillary results, allied health domains, and drugs, treatments, and procedures

Suggest all new healthcare information requirements at federal level mandate use of existing standards, with support for HL7 as the pre-eminent clinical information standard.

Suggest investigating options to support the HL7 Clinical Templates project.

The creation and adoption of such standards will create a level playing field for development of knowledge-based clinical decision support applications.

In the 1-4 year time frame:

For existing and new clinical information needs at the federal level, use the HL7 RIM and existing vocabulary standards to create interface implementation specification standards.

Areas needing to be covered include basic clinical ancillaries, and basic clinical documentation needs (signs, symptoms, diagnoses) (for both medicine and nursing).

Start working with vocabulary content providers to explore ways to resolve licensing and cost issues:

for clinical information interchange, the basic codes at the atomic level are most critical.

encoding of classification hierarchies and "knowledge" can be part of the level on which content providers compete.

resolve vocabulary content issues for pharmaceuticals. Information interchange requires at least a standard vocabulary at the generic, orderable level mapped to NDC codes.

In the 5-10 year time frame:

Work to support extension of HL7 RIM and vocabulary standards into all clinical specialty areas, psychology, and allied health.

4. Are there emerging areas, standards, or technologies that can contribute to the collection, storage, and communication of comparable PMRI?

What are they?

What are their strengths and weaknesses?

Can the private sector address these opportunities satisfactorily?

Since technology is evolving so rapidly (capacity doubles every 18 months; new media included), concentrate on information modeling and structure and vocabulary standards rather than technology standards.

18 months window is too fast for government action.

As above, it's important not to mistake "syntax" level standards with information modeling standards. The same is true for technology standards.

What role should the federal government play, if any

in 1-4 years (keep open, use interface engine technology to translate from one technology to the next)

in 5-10 years. (keep open, use interface engine technology to translate from one technology to the next)

Use the HL7 strategy of developing technolgy neutral information and vocabulary specifications.

With minimal "add-on" technolgy specifc layers. I.e. there is a methodolgy that allows the 'information-only' specification to be instantiated in any of the relevant technolgy modes.

Standards for images, waveforms and other binary data should also be technolgy neutral. (E.g. I can store a JPEG image in any technology.)

5. Is there a need to coordinate or otherwise facilitate the development of PMRI message format standards?

Note:

OACIS' primary interest is NOT in message format standards, but in standards developed from object information models that integrate standard vocabularies, such as HL7 version 3. We are interested in the messages and methods needed by such standards being expressed in technology neutral forms, so as to be able to take advantage of new technologies as they arise, and not be bound by out-moded technologies because they are too tightly linked to the particular information-model-based standard.

What type of coordination is needed or desirable?

I'd like to see more interaction with and support for the development of the HL7 RIM and HL7 Message Development Framework (MDF) from federal agencies.

the Government SIG within HL7 is a good example of this.

The federal government could also encourage the use of standards such as HL7 by requiring them for the clinical information gathering by such agencies as the CDC, etc.

I'd like to see more work on encouragement/subsidizing of existing standard codes to be used at the "basic" information level of these interoperability standards.

Federal support for US participation in ISO TC 215 might also be helpful.

What organizations or forums are available to facilitate this coordination?

HL7 has an existing RIM Harmonization process. that could be supported. It would need to be done carefully so as not to overwhelm the existing process.

I'm not sure that other SDO's have shown this ability for collaborative process.

What role should the federal government play, if any

in 1-4 years. See 3d above.

in 5-10 years. See 3d above.