Saturday, January 8, 2011

Call for Participation to the ONC S&I Framework and three S&I Initiatives

I'm stuck in LA for a day waiting for my plane to be fixed along with several other HL7 members on our way to the Working Group Meeting meeting in Sydney, Australia. While I'm waiting, I found this in my mailbox from Arien Malec, who led up the Direct Project...

 
I plan on participating as a committed member. I hope my colleagues in the US do as well.

 
    Keith


Greetings to the Direct Project Participants,

 
Because the Direct Project has not been nearly enough work, this is an invitation to participate in the Standards and Interoperability (S and I) Framework. The S and I Framework is launching today, with Calls for Participation for three initiatives (defined below) starting today and closing on January 28th. The S and I Framework is sponsored by the Office of the National Coordinator for Health Information Technology (ONC), through the Office for Interoperability and Standards (OIS).

 
For details about the upcoming S and I Framework Initiative Kick-Off Call, please visit the S and I Framework Wiki at http://wiki.siframework.org/

 
What is the S and I Framework?

 
The Standards and Interoperability (S and I) Framework is an investment by the country in a set of harmonized interoperability specifications to support national health outcomes and healthcare priorities, including Meaningful Use, the Nationwide Health Information Network, and the ongoing mission to create better care, better population health and cost reduction through delivery improvements.

 
What is needed to achieve this future are specific health interoperability initiatives that guide the design and development of a fully integrated and connected health information system to enhance the efficiency, quality and effectiveness of the delivery of healthcare. The focus of the S and I Framework is on delivering guidance to the health information technology community that can achieve lasting results in healthcare delivery improvements, through the development of content and technical specifications, the development of reusable tools and services, and the effort to unite stakeholders on common healthcare challenges.

 
What are S and I Framework Initiatives?
An S and I Initiative focuses on a single challenge with a set of value-creating goals and outcomes that will enhance efficiency, quality and effectiveness of the delivery of healthcare, through the development of content, technical specifications and reusable tools and services. The S and I Framework is currently launching three Initiatives:

 
How does it work?
The S and I Framework works with a set of motivated organizations and individuals who share the mission and goals of care delivery transformation through improved interoperability. The overall success of the S and I Framework is dependent upon volunteer experts from the healthcare industry and we welcome and encourage new volunteers to contribute to this evolving process. Participant collaboration and deliverable management will be organized through the use of the S and I Framework Wiki (http://wiki.siframework.org/).

 
How Do I Participate?
Any interested party is invited to get involved in S and I Framework Initiatives, participate in discussions and provide comments and feedback by joining the Wiki. However, only Committed Members have voting rights in the S and I consensus process. A Statement of Commitment is required to be a formal Committed Member of the S and I Framework. Participating organizations and individuals must (1) regularly attend weekly Initiative Group meetings, and (2) meaningfully participate in developing needed deliverables, including development of source code, documentation development, and supporting implementation of the S and I Framework pilot efforts.

 
To participate as a Committed Member, please register for access to the S and I Framework Wiki (http://wiki.siframework.org/) and submit a Statement of Commitment directly on the wiki.

 
To participate as a Non-Committed Member, please register for Wiki access and feel free to contribute comments or participate in discussions.

 
We look forward to working with you in advancing the S and I Framework and the ongoing mission to create better care, better population health and cost reduction through delivery improvements. Thank you again for your support and continued interest in healthcare interoperability.

 
Arien

Friday, January 7, 2011

I'm off to see the Wizard in Aus.

Actually, that about one of twenty different things I'll be up to over the next two weeks.  I won't list them all, but some include:

  1. I'll be attending the HL7 Working Group meeting in Sydney Australia.
  2. I'll be attending my first HL7 Board Meeting
  3. I'll have my last HL7 Structured Documents meeting as Cochair (I'll just be a committee member after Monday).
  4. I'll teaching classes on CCD, IHE XDS and CDA, and a workshop on how to develop an IHE profile
  5. I'll be attending my 7th IHE Connectathon.
  6. I'll be attending my first Connectathon Conference, where I will be presenting on development of IHE profiles.
  7. I'll be preparing materials for two sessions I'll be teaching for a John's Hopkins Informatic's program.
  8. I'll be reviewing meaningful use phase 2 proposals and related regulation as it arrives.
  9. I'll be preparing two presentations I'll be giving later this year at HIMSS11, one on social media, and another on development of IHE profiles (can you see a theme here)?
  10. I'll be promoting The CDA Book, now available for pre-order from my very own bookstore.
You can look forward to a week of blog posts from the HL7 Syndey WGM next week on what's new from HL7.  In the following week, expect a week's worth of posting on the IHE North American Connectathon.

I hope to see many of you in my (and your) travels in the coming weeks.

Oh, yeah, and the Wizard?  That's @omowizard.  I'm hoping we can cook up some interesting magic with respect to healthcare standards.

   Keith

P.S.  For those of you who've asked:  The manuscript is only available to educational institutions looking to review the book for use as a text in Informatics or Health IT classes.  Sorry, no early copies...  I'd love to get them to you sooner, but I just can't.

Thursday, January 6, 2011

2011 Healthcare Standards Calendar

I'm getting ready to head off to two events back to back, first to the HL7 Working Group Meeting in Sydney, then following that, the IHE Connectathon here back in Chicago. Sometimes I have trouble figuring out whether I'm going or coming, so I have to put together a calendar every year of significant events.

Below you see a Standards Event calendar that I have shared in Google Calendars. This calendar isn't intended to deal with minutia, but rather the big meetings, usually two-five day events related to Healthcare Standardization around the world. Feel free to send it invitations to your healthcare event.

I will monitor what is submitted, and try to keep it managable.

The e-mail address for this calendar is: 9h5apktq1vvr82k0ogvunvdsvo@group.calendar.google.com

If you want to be able to post events to it, drop me a line and I'll share it with you.


Definitions Matter

In more than two decades of software development, I've become quite accustomed to having to deal with product builds where the final changes to a product were strictly replacing its name. This is usually because marketing either had a very late brainstorm, or someone higher up decided that we needed something catchier for a name. I'd long been accustomed to using code phrases to identify a release because we never knew what the name was going to be ... sometimes even on purpose.  I've also been very wary of believing I understood something just because someone used a name or three word phrase I recognized. I usually ask for definitions.

So, the latest ONC blog post providing definitions for EMR and an EHR shouldn't really bother me.  But it does, in part because this office already wasted $100K defining these terms.  It was Bush's ONC and not Obama's that wasted the money, but the current office could have at least had the courtesy to reference the previous report rather than ignore it and redefine the terms.  But the original report should have been buried anyway ... maybe I would have been happier if ONC had acknowledged the errors in that report and then redefined the terms.

The next part of the post that annoys me is the qualitative judgement applied to the names, that an "EMR" product has certain limits on features (e.g., equivalence to digital paper) and information exchange which an "EHR" solves.

I spent 10 years working on linguistic software.  One of the things that I learned during that period of time is how definitions change over time.  Today's Electronic Medical Record is a completely different thing that what we had 5 years or a decade ago.  Perhaps it is time to change the name, and call it an Electronic Health Record.  I guess I'll wind up leaving that issue up to marketing and politicians.  What I do know is that changing the name of a thing doesn't change what it IS, just the perceptions of it.  I'll just have to remember to use the latest HealthIT Buzz words, but if I happen to use EMR, please remember that I mean EHR.  I haven't ever worked on anything as limited as what ONC describes.

Wednesday, January 5, 2011

A free chapter from the CDA Book

The first chapter of The CDA book describes how it is organized, and appears below.  The book will be available in print and in an electronic edition from Springer in the first half of this year.  If you are interested in previewing the book for use in your educational organization please contact me and I will make the manuscript available for your review.  Please include details of how you want to use the book in your request.

  Keith

P.S. The CDA book is now available for pre-order from Amazon!


Organization of the CDA Book
The CDA standard builds upon the HL7 Version 3 stack of standards.  In the lowest layer of that stack are standards on vocabulary and data types.  On top of those is the HL7 Reference Information Model. 
This book is organized into 4 major sections.  The Introduction describes clinical documents in general, and provides a brief history and overview of the CDA standard.  The Data Types section covers each of the data types used by the CDA standard in detail.  The Modeling section reviews the HL7 Reference Information Model and its application to the CDA Standard.  Finally, the Implementation section covers creation, display, validation of CDA documents and reviews key features of a number of implementation guides that use the CDA standard.

A brief overview of each of the sections and the chapters in those sections should help you to find what you need.

Section I: Introduction

Chapter 1 Clinical Documentation

This chapter describes the four C's; key properties of clinical documents and from them derives the six key characteristics use in the CDA standard.

Chapter 2 The HL7 Clinical Document Architecture

This chapter provides a brief history of the CDA standard, describes the overall structure of a CDA document, and explains how the standard provides for incremental levels of interoperability.

Chapter 3 Extensible Markup Language

XML is standard for producing structured content similar to what appears in HTML.  This chapter provides a brief overview of XML, elements, attributes, the XML declaration, namespaces, XML Schema, parsing technology, and character sets. 

Key Terms in the Introduction Section

Clinical Document – A clinical document is typically produced by a clinician and documents clinical observations and services provided to a patient or subject of care.
CDA Document – A CDA document is a clinical document stored in the CDA format.  All CDA Documents are clinical documents, but not all clinical documents are CDA documents.
Digital Signature – A digital signature is a collection of data produced by a cryptographic algorithm that can be used as proof that an entity authorized the signature of an electronic document.  Note that the US is one of the few countries that allow for both electronic and digital signatures in its laws and regulation.  Most other countries with policies on the use of electronic signatures for commerce require the use of digital signatures.
Electronic Signature – In the United States, an electronic signature is defined as “an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record.” [1] 
Medical Record – A patient’s medical record is the collection of documentation used and maintained by a healthcare provider organization to document the care provided to that patient.  It is also known as the patient chart.
Semantic Interoperability – The IEEE defines interoperability [2] as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.”   Semantic interoperability is focused on the ability to use and understand the information that has been exchanged.

Section II: Data Types
The most basic components to agree upon in communication are the data types to exchange.  The data types used in the CDA standard are defined by the HL7 Version 3 Data Types - Abstract Specification.  That specification is described as an abstract specification because it defines the properties, semantics and operations that can be performed on the data types rather than their concrete, computational representations.
The representation of these data types in XML is described in more detail by the XML Implementation Technology Specification included with the CDA Release 2.0 normative edition.   This specification makes the implementation of these data types more concrete, and indicates how the information is to be transmitted.
The hierarchy of HL7 Version 3 data types is shown below in Figure 4, along with the subdivisions of this section in which they are covered.

Figure 4 HL7 Version 3 Data Type Hierarchy


The most important features of commonly encountered data types used in CDA documents are covered in this chapter.  More detail can be found in the HL7 Data Types specification.  This section is divided into six chapters describing each of the groups of data types shown above.

Chapter 4 Basic Data Types

This chapter covers the ANY data type and simply valued types including Boolean and numeric quantities.  Included in this chapter is a discussion of what HL7 calls flavors of null, which represent the many different reasons why a value is not known.

Chapter 5 Text and Multimedia

This chapter describes how simple strings, text, images and other multimedia content are incorporated into a CDA document using the String (ST) and Encapsulated Data (ED) types.  The ED data type supports representation of any kind of multimedia content that has a MIME type associated with it.

Chapter 6 Demographic Data

Demographic data is one of the first things gathered about patients.  The eight different data types HL7 uses to support demographic data, including identifiers, names, addresses, telephone numbers and other communication addresses are explained in this chapter.

Chapter 7 Codes and Vocabularies

This chapter introduces the terms used to describe things in HL7 Version 3.  It defines key terms such as Concept, Code, Coding System, and Value Set, and explains the difference between pre- and post-coordination.  This chapter is an introduces material necessary to understand the following chapter on data types used for codes.

Chapter 8 Codes

Codes represent a concept, or idea.  This chapter describe the CD data type and its simpler variants that are used to described codes in the HL7 Version 3 standards.

Chapter 9 Dates and Times

Time is the essence of this chapter.  It describes the data types used to capture not just points in time, but intervals over time, and ways to express the timing events that recur periodically.  Time is especially important with medications.  This chapter shows how to represent the most common medication regimens in the CDA XML.

Chapter 10 Collections

Collections in HL7 are abstract types that can be used to create bags, lists or sets of any data type.  This chapter explains what these different types are, and how they work with the HL7 data types representing codes and quantities.

Section III: CDA Modeling
This describes HL7 Modeling and how it is applied to the Clinical Document Architecture.  Then it goes on to describe the CDA models for the three different levels of CDA content.

Chapter 11 HL7 Version 3 Modeling

This chapter describes that "language" of HL7 version 3, starting from the essential six RIM backbone classes of HL7 Version 3 which make up clinical statements.  It explains the meaning of "mood" as used in HL7 modeling, and how negation works in a clinical statement.  Along the way you will learn how HL7 model diagrams are interpreted as UML models, and to interpret the normative reprentations of the CDA standard.

Chapter 12 Clinical Document Infrastructure

This chapter describes the HL7 model for CDA and discusses features of the XML ITS that are used to generate the CDA XML from this model. 

Chapter 13 The CDA Header

Every clinical document has a context that describes the patient, the document author, the related encounter and metadata about the content of the document itself.  This chapter describes the RIM classes and XML representations of the CDA header that sets the context for the rest of the CDA document.

Chapter 14 The CDA Body

The CDA body represents the human readable content.  In the simplest form of CDA, this is just a file created using traditional documenting tools.  But CDA also has a standard format used to encode the narrative.  This chapter describes how both of these formats are included in a CDA document, and when the latter form is used, how it can be displayed in a browser using an XSLT transform.

Chapter 15 Clinical Statements in the CDA

The HL7 CDA standard "invented" the notion of a model for clinical statements.  This chapter explains what the components of clinical statements are, and how they can be used to represent the machine readable entries in the CDA document.

Section IV: Implementing CDA
Native support for CDA in applications requires a good bit of restructuring, so the most common way to start generating CDA documents is based on existing application interfaces.  These are most commonly implemented using HL7 Version 2 messages.  The next step after generating CDA documents is being able to do more than display them.  Applications need to be able access the content of CDA documents in meaningful ways.

To simplify application development, CDA can be constrained to support specific use cases.  There are a number of techniques that have been used to constrain CDA, and all of these are based on the HL7 Templates DSTU.  To support these implementations, application developers need to be able to ensure that the CDA content they receive is valid according to the constraints that have been applied.

A number of organizations, including HL7, IHE, the Continua Health Alliance, the European Smart Open Systems and ANSI/HITSP have created implementation guides using the techniques described previously.  The author has been engaged with each of these activities.

Chapter 16 HL7 Version 2 to CDA Release 2

The first place many organizations start when using the CDA standard is creating a CDA document from an existing HL7 Version 2 message.  This chapter describes how you can do that for three different types of HL7 Version 2 message most commonly converted into a CDA document.

Chapter 17 Extracting Data from a CDA Document

A document is only useful if it is read.  This brief chapter describes a few tools that you can use to "read" the clinical information contained within CDA document.  It also explains a technique to access context information associated with a clinical statement using XSLT, which is of the more common information extraction tools.

Chapter 18 Templates

There are more than 100 CDA implementation guides, and more than 500 definitions of CDA components, called templates, that have been defined by these guides.  This chapter explains what templates are, the different types, and how they are built.  It also explains the meaning of some of the terms used for asserting conformance to a template.  Finally, it explains how you can extend CDA to meet requirements that it does not directly support.

Chapter 19 Validating the Content of a CDA Document

This chapter demonstates some techniques that can be used to ensure that the CDA documents your applications are receiving conform to the rules being defined in CDA templates.  It covers four different techniques to validate content, and includes a discussion on validating narrative.

Chapter 20 Implementation Guides on CDA

Work on implementation guides began on CDA Release 2.0 before the ink was even dry on the standard. This chapter explores the history of several important CDA implementation guides.  It describes key features of these guides, and shows how the guides have influenced each other over the years.

Chapter 21 is for you to write.

References

[1]    Electronic Signatures in Global and National Commerce Act.  15 USC 7001, June 30, 2006.  Available on the web at http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?%20%20dbname=106_cong_public_laws&docid=f:publ229.106.pdf
[2]    Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.

Tuesday, January 4, 2011

The ONC Permanent Certification Rule for MeaningfulUse

ONC released the Permanent Certification Rule yesterday.  You can find the text here.  There were no real surprises in the final rule.  Below is a quick summary of the important changes in the rule.     
  • ONC intends to address the governance for the NW-HIN through a separate rulemaking. (p22)
  • §170.501 revised to acknowledge the possibility for ONC-ACBs to certify “other types of HIT" (p22)
  • §170.501 revised to clearly state requirements that ONC-ACBs must follow to maintain their status (p22)
  • §170.510 now allows orgs to certify other types of HIT besides Complete/Modular EHRs (p24)
  • §170.503 now allows 30-day submission for qualified orgs to compete to serve as the ONC-AA (p31)
  • §170.503 now extends review period of ONC-AA submissions to 60 days (p31)
  • §170.503 and §170.504 revised to allow time for reconsideration of an application to become an ONC-AA (p33)
  • §170.503 National Coordinator to start process at least 180 days before expiration of current ONC-AA (p34)
  • ONC will issue an NPRM on improper conduct of ONC-AAs and consequences (p35) 
  • §170.520(c) revised to indicate that there shall be only one ONC-AA (the Highlander Clause) (p57)
  • §170.523(f) revised to use the term developers rather than vendors (p64)
  • §170.523(h) revised to state that an ACB may only certify HIT tested by a NVLAP-accredited lab...
  • ... using test tools and test procedures that have been approved by the National Coordinator (p83)
  • §170.503 revised to require consistent plan for objective, valid, and reliable surveillance by ONC-ACBs (p92)
  • §170.530 revised to set 6-month expiration barring reapplication for ONC-ACB status after denial. (p107)
  • §170.545(a) clarified to ensure Complete EHRs certified in accordance with ALL adopted criteria (p119)
  • Definitions of  “development site,” “deployment site,” and “remote certification” added to §170.502 (p143)
  • §170.557 to require an ONC-ACB to provide remote certification for both development and deployment sites (p143)
  • §170.565 revised to provide ONC with the discretion to suspend an ONC-ACB’s operations (p152)
  • §170.523(j) clarifies that a suspended ONC-ACB must refund fees paid by developers seeking to withdraw (p153)
  • §170.523(h) now permits ACBs to rely on the results of prior testing (by ATCB or ACB) if criteria unchanged. (p190)
  • §170.540 revised to state that an ACB will renew every three years instead of every two years (p201)

Monday, January 3, 2011

PCAST and ...

I'm rereading the PCAST report for about the fifth time.  While I find some of the conclusions of this report challenging and worth commenting on more, the single most interesting thing in this report is how closely chapter 4 and 5 follow the software architecture of the Indivo project, which happens to be one of the SHARP grantees.  This influence appears on both the idea of "metadata tagged data elements" in Chapter 4 and in the privacy and security architecture in Chapter 5. The more I read about Indivo and in these sections, and the more I look for points of comparison, the more I find.  

Hmm...

Then I look at it again through different set of eyes and I see the influence of Amalga ...

Hmm...

And then again, there's my own interpretation of it with respect to HL7.

Hmm....

I don't know what to think now.