Kinds of Standards
Standards are like potato chips. You always need more than one to get the job done. And just as potato chips come in all shapes and flavors, so do standards. NIST has a decent classification of standards in NISTIR 6014, but in the Healthcare IT space, that's not really how most folks think about them. Most people classify standards by function.
Functionally, Health IT uses a variety of standards for (in no special order) e-Prescribing, payment (including claims and elligibility), quality measurement, clinical care (including lab reporting, medical records, and imaging results), administration (registration & admission), public health management (ELR and immunization reporting), Health Information Exchange, and privacy and security.
The problem with classifying standards functionally is that it isn't sufficient to get to the level of a single standard. Lab reporting still requires a bunch of different standards used together to get a lab results interface working. So standards geeks like me break it down a little bit differently. In order to perform a particular function, (e.g., lab reporting), you need a stack of standards supporting different layers.
If we take the laboratory reporting function, we could:
- Communicate over the Internet, using DNS for discovery, TCP/IP for basic communication, MLLP for framing (delimiting) a message, and
- Use the HL7 Version 2.5.1 syntax and ORU message models for content, and
- Identify Lab Orders and Results in LOINC, units of measure using UCUM, and body parts and organisms in SNOMED CT.
The OSI 7 layer model was one historical attempt to classify the stack, but it doesn't get at enough detail in the higher layers. The challenge with the OSI model today is that from the session layer (5), through the presentation layer (6) and application layer (7), protocols have become fractal. What was once considered an application layer protocol (HTTP), has become a building block upon which new protocols (e.g., SOAP and WS-*) are built supporting additional session, presentation and application models. And intertwined with the various layers are security protocols.
An Informatics Model for Health IT Standards
A new model for describing standards is needed. The model I use bridges between the technology space (OSI 7 Layer model), and the space that organizations like the US HIT Standards Committee and the Office of the National Coordinator work in, which is somewhere between technology and policy. Probably the best descriptor of that space is Informatics, a general term describing information science.
Transport
At the bottom-most layer is connectivity, which describes the set of standards that allow different systems to connect and communicate. This covers details about how two systems discover, initiate and engage in conversations. In the Health IT Informatics space, these are thought of as the "transport protocols", but in the technology space, that could mean any of the protocols traditionally assigned to many of the 7 layers in the OSI model.
Important sub-types of Transport standards include:
Important sub-types of Transport standards include:
- Discovery
- Connection
- Communication
Content
On top of transport we must describe the content that is communicated. This layer addresses basic syntax, data types, structure and meaning of that content. The content can describe simple data (e.g., an ECG Waveform), a summary of a clinical encounter, an order for a lab test, images (an X-ray) or other complex media (an MRI). Inside the content are specialized terms that communicate predefined semantics (vocabulary) or relationships (ontology) through the use of specific codes. The content is quite often structured, using some sort of model to represent various objects and relationships between them. Finally, content must often be rendered in order to be acted upon (e.g., images and documents) ,
Content is also fractal. Given the stack of standards that we use in Health IT, one piece of content may wrap around (envelope) another, supporting appropriate layering of transport, behavior or security for each system involved in the communication.
Important sub-types of content standards include:
Important sub-types of content standards include:
- Syntax
- Data Types
- Structure
- Semantics and Modeling
- Vocabulary
- Classification
- Ontology
- Rendering
Behavioral
After content, we need to describe the services performed or behavior expected of each participant during the communication. This is perhaps the most difficult part of standards in the Health IT space. Defining specific behaviors to be performed can be done in the form of an algorithm to be performed (e.g., matching patient demographics, computing a hash, or encrypting content) or by describing the services which are provided (often in terms of what is done on the content and transport side).
Important sub-types of transaction standards include:
Mapping Standards to the Model
Now that I've developed a model, the next test is to evaluate it against standards. Let's take a few different paradigms in Health Information exchange and look at how they match up.
SNOMED CT
SNOMED CT is an ontology standard. It not only identifies important terms, but also relates those terms to each other, for example, that disease X is a disorder of body part Y. As such, it embodies a certain amount of world knowledge in it that does more than just partition it into distinct kinds of things.
ICD-9-CM
ICD-9-CM is a classification standard. It identifies important terms, but does little to relate all of the different classifications it provides to other parts of itself. For example, there is nothing one "family" of codes in ICD-9-CM to another "family" of codes in that same system.
CDA Consolidation
The CDA Consolidation guide is a content standard. Syntax is based on XML and an XML Schema defined based on the HL7 Version 3 RIM (semantics and modeling), the CDA Standard (again modeling), and a variety of predefined vocabulary choices.
The DIRECT Project
The DIRECT Project is mostly a transport standard with some behavioral/service components.
IHE XDS
IHE XDS is again mostly a transport standard, with some service and content components. There is a good deal of content associated with the XDS Metadata. The fact that XDS fits into all three categories isn't surprising because it actually is an implementation guide describing how to use multiple standards to support an HIE use case.
NCPDP Script
NCPDP Script mostly addresses behavior at a message level. It's messages describe things like "New Prescription", "Prescription Change", or "Refill". The contents of the messages are described in terms of segments and fields (much like HL7 Version 2), with defined data types and vocabulary.
TLS
Transport Layer Security is mostly about behavior at a service level, with some notion of transport thrown in. As you read through TLS, you'll see that there are many services (encryption, authentication, non-repudiation, reliable communication) embedded in the standard.
After content, we need to describe the services performed or behavior expected of each participant during the communication. This is perhaps the most difficult part of standards in the Health IT space. Defining specific behaviors to be performed can be done in the form of an algorithm to be performed (e.g., matching patient demographics, computing a hash, or encrypting content) or by describing the services which are provided (often in terms of what is done on the content and transport side).
Important sub-types of transaction standards include:
- Algorithms
- Services
- Messages
Mapping Standards to the Model
Now that I've developed a model, the next test is to evaluate it against standards. Let's take a few different paradigms in Health Information exchange and look at how they match up.
SNOMED CT
SNOMED CT is an ontology standard. It not only identifies important terms, but also relates those terms to each other, for example, that disease X is a disorder of body part Y. As such, it embodies a certain amount of world knowledge in it that does more than just partition it into distinct kinds of things.
ICD-9-CM
ICD-9-CM is a classification standard. It identifies important terms, but does little to relate all of the different classifications it provides to other parts of itself. For example, there is nothing one "family" of codes in ICD-9-CM to another "family" of codes in that same system.
CDA Consolidation
The CDA Consolidation guide is a content standard. Syntax is based on XML and an XML Schema defined based on the HL7 Version 3 RIM (semantics and modeling), the CDA Standard (again modeling), and a variety of predefined vocabulary choices.
The DIRECT Project
The DIRECT Project is mostly a transport standard with some behavioral/service components.
IHE XDS
IHE XDS is again mostly a transport standard, with some service and content components. There is a good deal of content associated with the XDS Metadata. The fact that XDS fits into all three categories isn't surprising because it actually is an implementation guide describing how to use multiple standards to support an HIE use case.
NCPDP Script
NCPDP Script mostly addresses behavior at a message level. It's messages describe things like "New Prescription", "Prescription Change", or "Refill". The contents of the messages are described in terms of segments and fields (much like HL7 Version 2), with defined data types and vocabulary.
TLS
Transport Layer Security is mostly about behavior at a service level, with some notion of transport thrown in. As you read through TLS, you'll see that there are many services (encryption, authentication, non-repudiation, reliable communication) embedded in the standard.
A Note on Security
Throughout any communication, we must secure the information exchanged; making sure that that only authorized users or systems engage in communication, authenticating the identify of users or systems as needed, that secured functions are accessed in a controlled way, and that actions are logged to enable auditing. But security not a separate layer in the standards stack. It fits into, and takes advantage of transport, content and behavioral layers. Good security is designed in, not added as an afterthought. Because it is designed in at every level, it doesn't stand out as a separate layer in an an ontology describing the different layers of standards.
More could be done to assist both healthcare provider organizations and vendors in navigating this labyrinth. The discussion should start with characterizing the types of "conversations" that an various kinds of organization engage in, and then explaining how those conversations can be conducted on a standards-based substrate.
ReplyDeleteOf course, the discussion would eventually bleed back into internal operations, and in particular, the way clinical and other data is structured and stored. For example, SNOMED CT can't be used in data exchange if it has no place in the data that was stored prior a decision to exchange it with someone. There is a whole raft of questions about the current scope of the preferred coding standards, i.e., what clinical conversations they can and cannot facilitate. More to the point, HL7's clinical statement model imposes a set of (at least) implicit requirements on EMRs. A standards-compliant clinical statement can't be formulated if the data required to construct it hasn't been stored appropriately.
So far, in most of the discussions around standards, the requirements of a true problem-oriented medical record are mostly left out in the cold. That's a bit ironic given the POMR's considerable (albeit largely unacknowledged) relevance to Meaningful Use Stage 2, not to mention Stage 3.