A “PubMed” for HealthIT Standards

By way of a short introduction, this was the outline I submitted for my capstone project at OHSU.  As you might guess, starting my capstone means I'm in the home stretch.  I'll be writing more about this over the next six months.

  -- Keith

---

Capstone Project Charter for Keith W. Boone

Abstract

Newcomers to the use of health IT standards often ask the question “Where do I start?”.  It is often difficult to find applicable standards from the various organizations who are often the sole publishers of these documents.  This project will develop an online index supporting search and retrieval of the standards.  During the project, the index will be populated with content from several standards organizations.  The search capabilities will be piloted by interested individuals.  Data will be collected about usage of the system, and the utility of it to end users.

Introduction and Background

One of the most common questions asked by people who are trying to understand health IT standards is “Where do I start?”  Each standards development organization (SDO) has its own web site and is often the principle (and possibly the only) publisher of its standards.  Health IT implementers may need to identify or access content from multiple standards developers, either to compare the capabilities of each, or to implement a system that users each possibly in different ways.  Other health IT leaders have suggested that there be a common way to access this information[1], but none is yet available.

While the American National Standards Institute (ANSI) in the US provides an index[2] of all its approved standards and is an authorized source for standards from the International Organization for Standards (ISO), many organizations developing health IT standards are not members of ANSI, nor are all health IT standards necessarily available through ISO.  Furthermore, both organizations publish standards for more than just health IT systems, making it difficult to locate healthcare specifications by themselves.

Health Level 7 (HL7) has developed several specifications that can be applied to this effort.  The HL7 Templates Registry Business Requirements[3] specification describes metadata, policies, navigational, security, search and other capabilities for a registry of specifications using one or more of the HL7 standards.  They also published a metadata specification based upon a review 20 different standards or specifications from four different SDOs in support of unifying metadata across clinical quality standards[4].  Both specifications are applicable, but have not yet been implemented in a system that searches across specifications from multiple SDOs.

The United States Health Information Knowledgebase (USHIK)[5] provided by the Agency for Healthcare Research and Quality provides a standards portal[6] describing the data elements found in the ANSI Health Information Technology Standards Panel (HITSP), American Standards Committee (ASC) X12, and National Council on Prescription Drugs (NCPDP) standards.  This portal enables search for data elements available in a limited number of standards, but does not support searching for the standards themselves.

Project Design and Scope

The purpose of this project is to pilot a source of entry into the variety of different standards available to health IT implementers, informaticists and educators who want to learn more about health IT standards.  The concept is based loosely upon PubMed, a singular source of information for information from medical journals, but is applied to standards published by SDOs.  Rather than populating the information in the index manually, this project proposes to use existing information resources via RSS and/or Atom feeds provided by an authoritative source (e.g., the SDO itself).  Metadata information will be captured from this feed and indexed in a repository, allowing those interested in Health IT standards to search for, and compare applicable standards for different use cases.

Methods

The project will develop a metadata model for health IT standards based upon existing work, create a database to support search of this metadata, enable population of the database via commonly available Internet subscription formats (RSS and Atom feeds), and develop and test a search interface for accessing health IT standards.  The database will be populated with content from at least three SDOs.  Once populated, the pilot will be publicized to members of these SDOs and other organizations with an interest in learning more about health IT standards.

Data Collection

The site will be instrumented to capture usage statistics in two ways.  Google analytics will be used to capture specific details about web site interactions (links clicked, search paths used, et cetera).  Some individually identifiable data may be present in data captured via Google Analytics results (network and location).  The site will also be instrumented to collect other data from users including specific search requests, time on site, and feedback about the usefulness of the site.  Individually identifiable user information will not be captured or stored from this instrumentation (e.g., user identity, computer or network characteristics, et cetera).

Success Criteria

Upon completion of this project, I expect to have shown the capability to readily create an index of standards from multiple SDOs, the utility of such a site to the health IT community, and to have gathered feedback about how to improve searching of health IT standards.  Hopefully such a standards index will find a permanent home within the health IT standards community.

---

[1].     Halamka, J. The United States Health Information Knowledgebase. November 7, 2012. Life as a Healthcare CIO.  Available on the web at http://geekdoctor.blogspot.com/2012/11/the-united-states-health-information.html

[2].     ANSI Standards Store. American National Standards Institute. Available on the web at http://webstore.ansi.org/

[3].     Gower C, Curry J, Stechishin A, Shafarman M, Roberts J. HL7 Templates Registry Business Process Requirements Analysis, Release 1. December 2013. Health Level 7 International, Inc. Available on the web at http://www.hl7.org/implement/standards/product_brief.cfm?product_id=328

[4].     Boone K, Boxwala A, Rhodes B, Moehrke J. Clinical Quality Metadata Conceptual Model. December 11, 2014. Health Level 7 International, Inc. Available on the web at http://www.hl7.org/implement/standards/product_brief.cfm?product_id=391

[5].     Fitzmaurice JM, Donnelly J, Barnes R. The Standards and Interoperability Framework Portal in the United States Health Information Knowledgebase. September 29, 2011.  Standards and Interoperability Framework Initiative. Available on the web at http://wiki.siframework.org/file/view/USHIK+SIF+9.29.11p+v2.1.ppt

[6].     United States Health Information Knowledgebase. the Agency for Healthcare Research and Quality. Available on the web at https://ushik.ahrq.gov/

Datuit asserts patent may be applicable to HL7 FHIR

In my inbox this morning.  I haven't read the patent yet, but the first claim may be very recognizable to anyone working in IHE in 2003 - 2007.

   Keith

---

Datuit, LLC has advised HL7 of a recent patent they’ve received that MAY be applicable to the Fast Healthcare Interoperability Resources (FHIR®) Protocol Specification. The letter from Datuit alerting HL7 to the patent can be found at http://www.hl7.org/downloads/?DBKSPatentLetter 

An abstract of the patent (US8931039) entitled Method and System for a Document-based Knowledge System is available at:  https://www.google.com/patents/US8931039

Section 16 of the HL7 Governance and Operations Manual (GOM) addresses patents, and section 16.03.02 requires members/participants to issue a letter of assurance to HL7 for any patent  or patent applications felt to be applicable to HL7 Protocol Specifications. The letter of assurance from Datuit can be found here: http://www.hl7.org/downloads/?DBKSPatentInformationSheet

HL7 is not responsible for identifying patents for which a license may be required to implement an HL7 Protocol Specification (Section 02.02) or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. HL7 Headquarters shall notify the membership via email of any patent claims leveled against the HL7 Protocol Specifications. This announcement fulfills HL7’s requirement to notify the membership of this patent.

Karen Van Hentenryck

OHSU student project on Standards makes it through first gate in IHE

Over the summer I helped to teach BMI 516 Interoperability and Standards class at Oregon Health and Science University with Dr. Judy Logan and Harry Solomon. One of the class projects was to develop an IHE profile proposal, to enable students gain some experience with the sausage standards making process.

Two of these proposals have now been presented to two different IHE domains (this was not part of the student assignment). Harry "sponsored" a proposal on critical findings to the Radiology Domain, and I sponsored the following proposal on Bed Management to the Patient Care Coordination domain.

Personally, I think there's a great deal of value in this proposal. I'm thrilled with the positive response this got within IHE.  I'm also very glad that most of the developers of the proposal were also able to be present when it was proposed (even though the class is over). We'll be voting on moving work forward later today. I have no doubt this will be included in what the technical committee needs to review in a month.

   -- Keith

P.S. I think that if this goes forward, it becomes the BED profile (no acronym).
P.P.S. This was unanimously approved today to go forth for technical committee evaluation.

---

MeaningfulUse Stage3 Crosswalk

This spreadsheet cross walks from the Meaningful Use Objectives and Measures to the associated Certification Criteria and from thence to the standards. Thanks to Hans Buitendijk from Cerner for sharing this resource!  You can download it here.

   Keith

---

A theory of interoperability

Definitions of interoperability surround us, but all the attention in the world to definitions make very little difference in the end.

I have a theory that people will believe two systems are interoperable when they can observe that the systems work together in simple ways with little to no effort, and in complex ways with some effort. In neither case does that effort require substantial coordination between multiple parties (to achieve interoperability at the technical level).

This is a theory rather than a definition, and needs to be tested.  It's based on interoperability between applications I use on a regular basis.  Here are some of the applications and/or technologies I use, and some answers to whether or not I think they are interoperable.

Is a spreadsheet interoperable with a database?  Most are.  You can readily use a spreadsheet to query and update a database.

Is a word process interoperable with the PDF format?  Not quite.  You can easily generate PDFs, but you cannot read PDFs or update them without the full blown edition of Acrobat.

Is a word process interoperable with XML formats?  Again, not quite.  I can read and write a specific XML format (or perhaps even multiple depending on my word processor), but not generalizably so.  It takes a bit of work to get useful XML out of some word processing content.

Is social media interoperable with my Word Processor?  No.  Can I make it work?  Of course I can, but I don't think that my writing software to make it work fits within the definition of interoperability.

Is my e-mail interoperable with my blog?  Yes.  It readily supports simple stuff (notifications and postings), but not complex interactions without a good bit of work.

Is my e-mail interoperable with my tablet and smart-phone?  Yes.  Frustratingly though, I cannot do everything on my tablet that I could on my computer.  More than enough to make it frustrating to not be able to do more...

Is a patient registration system interoperable with an EHR or departmental system?  Most require a bit of work to perform this "simple" and even "designed" capability.  Is that interoperability?  Most users would probably say no.

What is your theory of interoperability?  How would you test it?

Catching up

Crystal Bloom, the new addition at my house

The last week has been somewhat overwhelming.  Of course there was the HL7 Working Group Meeting, and the Meaningful Use and Standards and Certification rule drop (two and a half reams of paper, thank the gods we don't print those things out any more).  And of course, even though some of us had a long weekend, I managed to fill mine up with other activities.  While contractors had finished my deck just before the WGM, I had a whole new set of kitchen appliances show up on Monday, and they were connected (mostly) and installed tuesday.  What part of Monday wasn't spent dealing with appliances was spent making sure that the barn was ready for a new horse.

Monday I barely managed to finish all the paperwork I needed to start my Capstone project at OHSU, and will be writing more about that here subsequently.  The long and short of it is that I'm in the homestretch of my Master's program.  While I had originally intended to write a Thesis, I looked at the time commitment to do that (there's an additional nine hours that would be associated with that track), and decided that I really wanted to graduate the same year as my daughter (this June if all goes well).

I also just submitted a new profile proposal for bed management to IHE Patient Care Coordination just under the wire.  Fortunately, I didn't have to write any of it.  It was prepared by four OHSU students in the Summer term of the OHSU Standards and Interoperability class.  I'll just be the chief promoter of it in IHE.  It's a new area for PCC, but also completely in line with its mission. The coordination necessary to get a patient into a bed within a hospital requires a good deal of interaction with multiple different Health IT solutions.

Last week at the HL7 Working group meeting I did manage to get approval from the CDS workgroup for an adoption ballot of the IHE Guideline Appropriate Ordering profile in HL7, and also cosponsor approval from Healthcare Standards Integration.  I failed to get elected chair of that workgroup, but it's now been announced that I was re-elected to the HL7 Board.  I've known for some time, so when people congratulated me, it often took me a moment to realize why.  Although it was much more obvious when someone offered me the more traditional dual "congratulations and condolences" on the new role.

Relevant and Pertinent project continues on its merry way, I expect to have some more exciting announcements about that project fairly soon.

HL7 (and I) will shortly (not next week, but likely the week after) be producing a members only webinar on the new regulations.

The CCDA <-> FHIR conversion work continues along at an interrupted pace as my day job continues to interfere with my day job.  It goes with the territory I think.

Anyway, that's what's new with me.  What's new everywhere else?  I keep wondering what I've missed, there's bound to be something.

   Keith

First you mine the data ...

CDS Hooks for FHIR is about hooking a trigger event, such as the creation of a prescription or other order.  When I thought about this, I was reminded of event driven programming models in the early days of window-based application development.  Anyone who has ever written user interface code for Windows, the Mac, or X-Windows is familiar with the ever pervasive event loop.  In fact, many UI development models today still have an event loop somewhere in their midst, it's just better hidden.

So, what events would we want to hook?  Josh is incredibly focused on reality, and so has limited his examples to three common events.  I was a bit more curious, because CDS is NOT the only thing that may want to hook into the EHR system. In HL7, we have a plethora "trigger events" and associated payloads already specified in the HL7 Version 2 and Version 3 standards.

HL7 Version 2 describes a trigger event as something that "... creates the need for data to flow among systems." (see section 2.3.1 of HL7 Version 2.8.2).

In HL7 Version 3: "A trigger event is an explicit set of conditions that initiate the transfer of information between system components (application roles). It is a real-world event such as the placing of a laboratory order or drug order. The trigger event must be systematically recognizable by an automated system." (See Section 3.4 of the HL7 Version 3 Guide).

The 2015 Normative edition of Version 3 describes more than 700 trigger events across some 60 separate specifications from nearly two dozen working groups.  While you might expect to find a complete listing of these in the HL7 V3 code system Trigger Event ID, you won't.  Instead, you'll have to search across all the specs.  You can find an XSL Transform that will grab the essential data here.  It may not be perfect, but it gets quite a bit from the Normative edition.  The same thing should also work from any downloadable V3 collection, including a ballot draft.  Associated with the trigger events are some 60 odd "Message Types" which focus on a RIM class related to the message.

HL7 Version 2.8.2 defines some 300+ trigger events, 200+ message structures, and around 150 message types.  You can find these in Chapter 2C - Control Code Tables, in tables 0003 Event Type, 0354 Message Structure and 0076 Message Type.

The HL7 EHR Functional model also describes some functions that could be useful for identifying trigger events.  Essentially any verb/object pair in the EHR FM could identify a trigger event and the associated payload.  IHE specifications also identify trigger events, but a clever person might recognize that since these are almost all based on HL7 or DICOM messages or services, that a complete list from those sources would cover the IHE work.

Getting the same information out of DICOM is perhaps a bit more challenging (for me at least).  I'm sure it's there (because DICOM has some very well structured specifications), but I don't really know where to look.  SOP Classes seemed like a good start since they combine a service with an information object definition, but I don't really know how to read those definitions, and there may be a better way to mine trigger events from DICOM.  Hopefully a DICOM expert might chime in on this.

As a result of my data mining, I've got over 1000 trigger events to look at, each associated with a data structure that I can map (in most cases) to one or more principal FHIR resources.  For example, A01 Admit/visit notification clearly associates with Encounter.  There are some messages that don't have a good mapping to a FHIR resource, often because those resources don't exist yet in DSTU 2 (e.g., Consent).

I'm still in the analysis process with this data, when I get it a little bit further along, I'll share more. For now, you at least know where to find it, and can follow along if you'd like.

   -- Keith

---

I've updated the colors and fonts to make the blog easier to read. Let me know if you like the new scheme.