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.

Semper ascendens deinceps

Yesterday was Wednesday at the HL7 Working Group Meeting, and if you are familiar with this blog you might have been surprised that I didn't follow my usual pattern.  My excuse was that the meaningful use and standards and certification rules came out three days earlier than I had expected (after all, we have a holiday weekend coming up).

In any case, this year I'm going to do something a bit different.  I've been giving out Ad Hoc Harley awards for more than five years now, its time to mix things up a bit.  This year I'm starting something new.  The purpose of the Ad hocs was to ensure that people who would otherwise go unrecognized for their important contributions get some early recognition.  It's somewhat of an unwritten rule that most senior people in the field who've already gotten a lot of recognition probably won't get an Ad Hoc (although some contributions have warranted and received it).

I've written about being a mentor and a mentee before.  The next group of people have been some of my formative mentors.  These folks are listed in the order that I met them, rather than any other.

Dr. Dan Russler was one of my first mentors in HL7.  He taught me a great deal about problem oriented medical records, the details behind the HL7 Concern and Condition models, and introduced me to the formative work of Dr. Larry Weed.  He and I cochaired Patient Care Coordination in the early years, and he was also very involved in early work on the Care Record Summary and the Continuity of Care Document.  Dan's a teacher now, and always was.

Dr. Susan Matney is a nurse, informaticist and vocabularist extraordinaire.  She taught me a great deal of what I know about nursing AND nursing vocabularies, including CCC, NANDA, NIC, NOC and SNOMED CT.  She was instrumental in some of the early HITSP work on addressing nursing vocabulary, and that was also formative in IHE and elsewhere.  She has a recently minted Ph.D., which is really only another form of belated recognition of her contributions.

Dr. Todd Rothenhaus is a fellow of the American College of Physicians, and one of the first CMIO's I'd ever worked with directly (although that title came after we worked together).  With his help, IHE produced a family of profiles around emergency care, including ED Referral (EDR), Emergency Department Encounter Summary (EDES), and moved into a round of profiles on emergency transport.

Dr. Laura Heerman-Langford taught me how to look through the eyes of a user of specifications, and is another who also taught me a great deal about nursing. When she first came to IHE Patient Care Coordination, she'd already had a long tenure in HL7 Patient Care (where she is still cochair).  Even with her great technical knowledge, she has always been looking at work from the eyes of someone who will have to use it.  While this is almost constantly threatening to an author, she's always been able to provide her insights in a way that enabled the best outcomes: Clearer and more comprehensible specifications.

Having again violated conventions by introducing the recipients, I'll now tell you what the award is.

Dr.'s Russler, Matney, Rothenhaus and Heerman-Langford are hereby inducted into the 2015 class of the Ladies and Lords of the Ad Hoc Harley.  Like fellowships, this is an exclusive club, and it does have some limitations on membership.  Ladies and Lords must already have been recognized in the past for their contrinbutions (this must not be the first recognition), and their contributions must be long-term and sustaining.  I'm not sure that this will be an annual thing (that would be too predictable for me), but it will be repeated.

2015 Ladies and Lords of the Ad Hoc Harley

Dan Russler, Susan Matney, Todd Rothenhaus and Laura Heerman-Langford Semper ascendens deinceps
(Ever riding forward)

---

P.S. As with similar recognitions, this one comes with its own set of letters you can apply after your name, of similar stature with FHL7, FACMImimi, and now LLAHH

The 2015 Edition Certification and Standards Rule

In case you've been in a cave (or at an HL7 working group meeting) and haven't heard, the Meaningful Use Incentives and 2015 Standards and Certification rules dropped yesterday.  I already had a lot on my plate yester-eve, so my Twitter review didn't start until about 10:30pm (much to the chagrin of of some folks).

Overall, I think this final rule is a win-win.  One of the big changes I was very happy to see was the change from C-CDA 2.0 to the new C-CDA 2.1 that HL7 members developed in response to the proposed rule in record time (see my posts on that story).  I got some very complimentary feedback on my work and that of Bret Marquard on that project, and I want to thank him again for his tremendous efforts in making that happen.

What follows below is essentially an edit of that twitter feed in case you weren't up til 2:00am reading the rule like I was.

First, skip to page 5 (skip the background drivel).  Starting there you will find an overview of what is in the rule.  Highlights include:

1. Updated standards and vocabulary for the new common clinical data set (CCDS).
2. A functionally defined API (ONC is headed towards, but did not name FHIR) for access to CCDS content.  Most of the industry is moving towards FHIR here.
3. A shift from EHR focus to Health IT focus.
4. Capture of sensitive health disparity data was retained, and includes not just gender, race and ethnicity, but also sexual identity, and social, psychological and behavioral data elements.
5. A continued emphasis on privacy and security.
6. More attention to user-centered design.
7. Support for better patient matching (but not as severe as orginally proposed),
8. About 4-5% of the document is devoted to implanted medical device identification, a very hot topic. 
9. It claims to provide more flexibility and time, and I certainly see some of the flexibility in this rule, but have to look at the incentives rule to answer more about "Time".

A few other notes from the Executive Summary:

• The API must support a query of any individual data item in the CCDS, as well as all at once (p7).
• It introduces new C-CDA requirements to improve reliability. 
• It updates the 2014 Base EHR to add smoking status demographics, includes the API and implantable device list requirements.  
• Much of the incentive based material, such as definition of Certified EHR Technology, CQM requirements and meaningful use measurement requirements have moved to the Incentive rule, rather than the 2015 edition rule.
• ONC estimates the total industry cost estimated at $330M +/- $70M (p15), and I might remind you that HITECH came out of an economic recovery bill.  

Skip the next ten or so pages (history of past regulation isn't that useful for most) to start again at page 26.

Not Adopted and Unchanged Material

Proposed criteria NOT adopted includes:

LOINC coding of Vital Signs, Family History using HL7 Pedigree standards, patient list, EMAR, Clinical Decision Support Knowledge Artifact and Service standards, Accessibility technology, Healthcare Provider Directory (HPD), and Electronic Submission of Medical Documents (esMD).

Criteria that is essentially unchanged includes:

CPOE for Meds, Labs and Imaging; drug and allergy checking, drug formulary checks, meds and allergy lists, smoking status, transmission of reportable lab results, privacy and security criteria regarding: Authentication, Access Control, Authorization, and Audit. Also amendments, automatic access time out, provision for emergency access, encryption of data on end-user devices, and accounting for disclosures.

New and Revised:

Pages 29-30 contain a good table describing the previous as well as new and revised stuff, I just wish this material was available not just in a machine and human readable format (PDF), but also a computable one like IETF RFC-4180.  I'm hoping ONC will do that as they have in the past.  For the most part, the remainder of this post addresses the new and revised material, and in some cases, the not adopted material.

Page 34 is simply a one page excuse for lack of use of consensus standards when they applied Direct. I'm grateful for this recognition that Direct falls into that category, and never became a standard even though that was the original intent.

Vocabulary

One vocabulary, they kept the provisions on use of NDC Vaccine codes👎, as is CDC Race and Ethnicity 👍.  One of the big changes the latter introduces is that the EHR must now support capture of multiple ethnicities, something that is not required by OMB, nor was required or supported previously in C-CDA.  We can address that latter need through an extension created for this purpose by structured documents.  ONC and NIST can address how multiple ethnicities can be used in a sub-regulatory way.  As this follows the pattern necessary for multiple race, I foresee no difficulties with applying that process.

There's a useful table of vocabulary OIDs used in Meaningful Use on page 39 (note, that's a useful table of OIDs, not a table of useful OIDs).

Psycho-social Data Capture

On the psycho-social front, I noted that gender identity value set includes Male, Female, trans (male/female), genderqueer, and other categories.  My kids can tell you that this is a very limited set, but it at least begins the recognition that gender identity is an issue associated with treatment disparities.  Elsewhere on the psycho-social-behavioral data capture front, the EHR needs to support it, even though the physician (under stage 3) is not required to use that capability.

Discussion of device identifiers takes up 1/25 (approximately) of the rule text.  The short summary is that yes, you have to store and parse them, but FDA can help.

C-CDA

On C-CDA, you'll have to support read of both 1.1 and 2.1 releases, and output 2.1 content that is backwards compatible with 1.1.  They did limit the requirements to support only the CCD, Referral Note and in the case of inpatient settings, the discharge summary.  Furthermore, systems must be able to support validation and error checking on both releases on import/incorporate/display.  A gold standard sample document is being prepared to a) show implementers how things should be done, and b) ensure that they can produce something like that.  On the topic of relevant and pertinent content, they remind us that providers can decide what to include, but the EHR must have the ability to send all content.  To further support relevant and pertinent, they also require the EHR to have the ability to support display of only a particular section (or sections), set user preferences for display order, and to set the number of initial sections to display.  Note, creating and receiving a C-CDA document are now separate meaningful criteria, which makes it quite nice for folks who are developing systems that just generate the C-CDA to be integrated with others that handle the transmit/receive capabilities.

Patient Matching

Some of the Patient matching requirements remained in the rule, but the CAQH Core rules were not adopted for a variety of good reasons (mostly having to do with the fact that this normalization is done at the receiver side).  C-CDA does support the needs here.
They did note a challenge in that prior address is not explicitly called out in C-CDA, nor is usable period.  However, I will note that since C-CDA is based upon CDA, and those capabilities are still present, just not specifically called out in C-CDA (nor where they in CCD).  So, they can still be used to identify historical data.

Data Provenance and Data Segmentation for Privacy

Capturing and recording Data Provenance using the HL7 DPROV was suggested, but has been dropped from the final rule, essentially as not being ready for prime time (my words, not theirs). The provisions for Data Segmentation for Privacy (DS4P) have been included, but are not required for the incentive rule or the base EHR capability, so DS4P is essentially optional.

Reconciliation

I'm still crying inside that ONC essentially adopts the IHE requirements its RECON profile for incorporation of data, but does not name it.

ePrescribing includes 10 NCPD transactions, including history, but does not require NCPDP structured sig as it is deemed to be a bit immature.

Patient Access

A number of changes to VDT and other patient access requirements really made my day.  View, Download and Transmit are expected to support imaging reports and lab results.  One of the new requirements on transmit is that an EHR must support transmit not just to a Direct address, but also to any e-mail address (unencrypted).  Patients, under current HIPAA regulations, may presently ask that data be disclosed to them via unencrypted email, although that provision is little known.  After a provider has a certified EHR product (to the 2015 edition criteria), docs won't be able to use the excuse that "we don't have that capability" when a patient requests it.  If they do, I imagine this page might get more hits (although it needs to be made clear that access falls under privacy and security).

The API requirements are also noted as being able to support patient access criteria.

API

API requirements have been split up into three separate pieces.  While FHIR was mentioned several times in the rule, it was not named for API requirements.  As ONC states a couple of times: "we decline to recommend a specific standard at this time, although we intend to do so in a future."  

That last statement is a big hint to everyone.  While Meaningful Use may go away, Certification seems to be here to stay.

   -- Keith

---

P.S. The first draft of the bookmarked final rule can be found here, thanks again to Corey Spears. This is just as much as he could get bookmarked so far, expect updates.
P.P.S. You can find the changed tracked regulatory text here.  I extracted (using Acrobat) the proposed and final regs from the PDF into Word, and then applied Word's document comparison to get the edits.  Your mileage from this process may vary.
P.P.P.S. ONC's presentation from today is here.

IHE extends call for proposals to October 16

Greetings IHE Members,

The PCC Domain will be extending the Call for Proposal deadline through October 16, 2015. Interested parties are invited to submit a brief proposal (form attached) for new IHE Profiles and/or White Papers to be considered for development in the new Publication Cycle.

IHE International's New Membership Model Effective October 1, 2015

Effective October 1, 2015, IHE International is moving to a new fee-based membership. To ensure your organization can participate and advocate their proposal throughout the entire Planning and Development Cycle please read the information provided at the end of this email.  Contact membership@ihe.net to renew today. 

All Proposals must follow the structure and format of the attached Brief IHE Proposal Template, specifically addressing the following:

1. What is the problem you propose to solve by this proposal, and how is that problem expressed in practice (e.g., a use case)?
2. How would fixing this problem improve health care in practice?
3. What specific components of standards could be used to solve this problem?
4. Your proposal should identify one or more potential editor(s) in the event that the proposal is selected for further evaluation and possible development. Please include some indication of the business and/or clinical case surrounding the situation when describing the problem. For example, is there an economic motivation for addressing this problem immediately?
5. Watch the online webinar to learn more about submitting a proposal and the proposal process.

Summary of IHE's Multi-Phase Proposal Process

Submit Brief Proposals by September 26, 2015

The PCC Domain will consider all proposals submitted through October 16, 2015. Submit a Brief Proposal with the attached form to the domain email listed below.

Committee	Domain Email
PCC Planning Committee	pcc@ihe.net

Planning Committee's Proposal Review Webinars- Decision Meetings

Webinars are held during the last weeks of September thru early October.  All Proposal authors are required to present a 15 min. summary of their Brief Proposal on one of these Webinars. Exact dates will be announced in September.  Please anticipate participating on 1-3 webinars. These Webinars will be decision meetings and count towards retaining/obtaining active voting rights.

2015-2016 Planning Proposal Evaluation Kickoff

RSVP Today! October 22-23, 2015 in Oakbrook, IL

We urge those who submit proposals or white papers to attend the Planning Proposal Evaluation Kickoff Meeting in person or phone. In-person advocacy has proven to be the most effective way to ensure your brief proposal are understood and accepted by the committee. 

2015-2016 Technical Committee Proposal Evaluation Meeting

Save the Date! The week of November 12-13, 2015 in Oakbrook, IL.  Proposals that are accepted at the Planning Proposal Evaluation Kickoff Meeting  will be required to write and present a detailed proposal during the Technical Proposal Evaluation Meeting.

Help Promote IHE Call for Proposals

All IHE members and industry partners are invited to share this announcement with their committee mailing lists and other interested parties. Additional information is maintained on the IHE Wiki.

IHE International Membership Updates

• Organizational members that have not paid their annual membership fee will be unable to actively participate in committee activities effective October 1, 2015. Upon payment of membership, organizational members can participate in IHE International and restore voting rights.  Historical voting rights will be re-instated after payment is made and pending that the member organization has met the attendance requirements outlined in Section 10.2.6 of the IHE Principles of Governance.
• Only current paid IHE International members are permitted to work on the development of IHE Profiles and Technical Frameworks. Membership will be required for the following events or activities:
• All face-to-face planning and technical meetings
• Weekly committee teleconferences and meetings
• Committee votes
• Documentation and editing of IHE International's Profiles and Technical Frameworks
•  Non-members can participate in the following ways:
• May occasionally participate in committee meetings as observers, at the discretion of the committee co-chairs.  Must complete Request for Observer Status at IHE Domain Committee Meeting form at least five working days prior to any specific meeting you wish to attend.
• Provide feedback during the Public Comment phase

We look forward to working with you during the IHE 2016-2017 Publication Cycle. Please contact Nancy Ramirez at nramirez@himss.org  if you have any additional questions or need further assistance.

Kind Regards,

Nancy Ramirez

Coordinator, Informatics & IHE Liaison

33 West Monroe Street, Suite 1700|Chicago, IL 60603

What is workflow?

A 1921 reference to the term Workflow as we use it today, from The Railway Engineer Volume 42

I devoted most of Q3 and all of Q4 at the HL7 Working group meeting today in a session hosted by Orders and Observations, and including participants from Financial Management, Patient Care, Modelling and Methodology, Imaging Integration, Pharmacy, Healthcare Standards Integration, Security and FHIR Infrastructure work groups to discuss the addition of workflow to FHIR DSTU 2.1 in the coming months.

There's a ton of information packed into that single sentence, so let me parse that for you:

1. A lot of people in HL7 are interested in workflow.
2. It will be a focal point of the next FHIR DSTU release, presently known as 2.1.
3. The material will be developed fairly quickly (at least to support FHIR connectathon testing), and will likely be balloted in the next six months (although unlikely to be balloted in the next cycle due to the short time frame for it).

One of the things we didn't yet agree upon is what we mean by workflow, and it was fairly clear that what a lot of people were talking about addressed workflow at a variety of different levels.

Many workflow standards exist today without even defining what a workflow is.  BPMN is a perfect example, as is OASIS Human Task (the standard IHE used to support Cross-Enterprise Document Workflow).  Fortunately, the Workflow Management Coalition (WfMC) defines workflow in their glossary as:

The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.

This is a fairly straightforward definition, which I will build upon further based on my work with BPMN over the past year or so.  Some of the terms in this definition are a bit slanted towards business process automation and workflow management tools, but for the most part what it says can readily be applied to what we are trying to do with workflow in healthcare at HL7 and elsewhere.

From my perspective:

Workflow is the creation of a good or service through the collaboration of multiple parties performing a defined process.

Each component of this definition is essential.
An activity that does not provide some utility (the good or service) is at best boring, and at worst wasteful.

• If only a single party (person, organization or system) is involved, then we don't need to manage it in the same way as when is is performed by multiple parties, at at best our "workflow" becomes a process or algorithm by which a good or service is produced.  So without multiple parties, our need to manage "workflow" disappears.  
• The defined process is also essential, because that is how we can measure progress through a workflow.

It's fairly clear in many discussions that I have had with others about workflow that some of the essentials are missing when workflow is being discussed.  People often talk about "their workflow", but what they often mean is their process, which moves us a bit further along to the next definition:

A process is a defined sequence of activities and decisions to be performed by an entity that has a clear starting and ending point, and may have inputs and outputs.

Without clear endpoints, we cannot tell how far along a process is.  Without sequence, we cannot ensure that steps occur in the appropriate order when necessary. Decision points allow for alteration or repetition of a process based upon defined criteria [wash, rinse, repeat until done]. Inputs and outputs provide for interim measurable results that show progression through the workflow, and through which quality of the process can be evaluated and managed.

The parties, entities or whatever phrase you might want to apply are simply autonomous actors, things able to do something of their own volition having been appropriately prepared.  That can be a person, an organization, or a system, or some entity composed of two or more of those parts.

Finally,

An activity is a unit of work which can be treated atomically.  Activities are performed by people, organizations or systems (or by any composition of the same).  Activities may be further broken down, in which case it can be viewed as a "subprocess."

Some processes are comprised of a single activity.  When my daughter (either of them) creates a drawing, they may not have a defined process for how they do that activity (arguably, it is very ad hoc).  But there is a very clear beginning point (a blank page), and an end-point, which often includes a decision to be made (an artist decision, a filled page, or bed-time, whichever comes first ;-).  So even a not very well defined activity can have a moderately well defined process.

The definitions I've provided are clearly informed by BPMN, but are also consistent with other definitions of workflow found elsewhere, going back as far as 1921.

I don't know that it is all that important to get people to agree with MY definitions, so long as we agree to work from some definition.  I think making sure that we understand the distinctions between the concepts associated with (in my definitions) the terms workflow, process and activity, we'll be able to move forward successfully.

One of the important distinctions that Lloyd made in the meeting is that Resources aren't activities. There is a difference between "Resource" and "Service", in that a resource can describe what needs to be done, e.g., a request or order.  The service actually executes the activity, and as a result may alter, create, delete or access other resources.  What FHIR operates on today are resources, and it includes the basic functions Create, Read, Update and Delete on those resources.  Those familiar with security ontologies will realize is that the missing action from FHIR resources is execute, and that is what services enable, the execution of a process.  And enabling collaboration (through FHIR) among multiple processes will result in integrated workflow, for perhaps the first time in healthcare.

CDS on FHIR

Yesterday I attended a meeting containing a blue ribbon panel of EHR and CDS standards geeks in a packed room at Children's Hospital, hosted by Josh Mandel, and attended by head FHIR chief Grahame Grieve.  Josh is probably the best example of a FHIR chief that we have in this country. His work on SMART is already being adopted by EHR systems and healthcare entities in this country. We talked about a new way to integrate clinical decision support into the EHR, which I'll describe below.

Essentially the idea is to have applications register with an EHR their desire to be notified at particular points in the provider workflow, and to request specific information be provided to them. Associated with the application registration are:

1. The service URL to invoke: [base]/$cds-hook
2. The identifier for the trigger event (e.g., medication-prescribe)
3. An optional pre-fetch template to obtain data to pass to the service URL in addition to the resource associated with the trigger event.

The service will pass back zero or more "action cards" which can be used to tell the EHR the advice given by the CDS service.  The EHR can decide on how to integrate that advice into the physician workflow.  You can find more details on Josh's wiki for the project.

This is quite cool, and works well with existing patterns of CDS use.  

1. Information action cards provide sort of an extended InfoButton capability.
2. Other action cards fit well within patterns established by FHIR Care Provision (e.g., ReferralRequest and ProcedureRequest), MedicationOrder, and Workflow (e.g., Order, DeviceUseRequest, SupplyRequest, etc.).
3. Still other action cards can integrate with a cloud-based or locally hosted HTTP service to provide additional user interaction, and be integrated into the EHR ala SMART kinds of interfaces.
4. Yet other action cards (discussed in the meeting, but not yet described on Josh's wiki) might support other capabilities within the workflow, perhaps to address the CDS integration itself. One example of this we discussed at the meeting was that when a service is not covered by a payer (as determined by one service), going into another service that looks at determining medical necessity might not be needful).

A couple of comments come to my mind when looking at this:

1. I'll bet I can find hundreds of trigger events and associated contexts for CDS from HL7 Version 2, Version 3, InfoButton, HITSP, IHE and other specifications.  This is more of a data mining exercise for trigger events than anything else.
2. Separately, each trigger event may want to be associated with one or more principle resources that describe the data associated with the trigger event.  For example, for the medication-prescribe event listed above, the likely candidate would be MedicationOrder.
3. The way that the pre-fetch template works is a quite generalizable mechanism that supports many different integrations.  

That last comment deserves a lot more expansion, because I think it is the keystone to advancement in many standards.

This mechanism generalizes specific templates for sending data for an integration.  For example, this is how IHE had previously integrated forms based data capture in the Request Form for Data Capture (RFD) profile, with the needs for specific data as described in the Clincial Research Document (CRD) profile.  A similar mechanism has been used by CDS implementors by providing recommendations based on the content of a Virtual Medical Records (VMR) delivered through a CCD document.  It would also work quite well to specify the data requirements for a quality measure. By "registering" the pre-fetch bundle with the EHR, the CDS system allows the "question" to come to the data (as we did for Query Health), and the EHR to decide (based on the policies of its organization) how to respond to this query.  

Fortunately, this meeting came at a time when both CDS and Clincial Quality Measures in FHIR are currently being discussed in HL7, and can so impact both of those activities prior to them becoming DSTUs.  I'll very likely be making this point next week at the working group meeting in Atlanta, but if I don't I can count on many of the luminaries in the room yesterday to also do so.

I was thrilled to be invited to this event, and am really grateful for Josh's continuing his past outstanding work.  He is clearly no "one-shot" wonder, and I look forward to his future contributions to the world of standards.

   Keith

P.S. One of the values we have in the "slow-down" of ONC on the development of standards is the luxury of time to do things right, instead of against an arbitrary deadline.  That makes me hopeful that CDS, instead of being the unfindable Holy Grail of EHR integration, would instead become a commonplace mechanism for building the best EHR system one could imagine.