HIMSS Interoperability & Standards Podcast

Transcription

1 Featured Speaker: Hans Buitendijk, M.Sc., FHL7 HS Standards & Regulation Manager, Siemens Healthcare SUMMARY: Hans Buitendijk, a leader in the effort to develop appropriate standards and guidance across the healthcare industry, is an HL7 Board member, co-chair of various HL7 workgroups and committees, vice-chair of the EHRA Standards & Interoperability Workgroup, a member of the recently formed Carequality Steering Committee and co-lead on the ONC s Standards and Interoperability Framework Initiative focusing on laboratory orders and results. Hans speaks with HIMSS Vice President for Informatics Joyce Sensmeier on the topic of standards maturity in healthcare IT. The discussion addresses the current status of interoperability standards adoption and implementation, exactly what is meant by the concept of a mature standard, and recommendations on moving the industry toward efficient development and widespread adoption of truly mature standards for interoperability. Recorded May 21, 2014 TRANSCRIPT: Joyce Sensmeier: Welcome to the HIMSS Interoperability and Standards Podcast Series. My name is Joyce Sensmeier, and I m the Vice President of Informatics at HIMSS. My guest today is Hans Buitendijk. Hans is a senior expert in the area of standards and regulatory activities at Siemens Healthcare. Over the last ten years, he has also served off and on, and is currently on, the Board of HL7 International in various capacities. Currently within HL7, Hans is Co-Chair of the Orders and Observations Workgroup, also Co-Chair of the Clinical Statement Workgroup and Vice Chair of the EHRA Standards and Interoperability Workgroup. He also co-leads the HL7 Standards and Interoperability Framework Initiative, focusing on laboratory transactions. We are fortunate to have Hans with us today, as he is a highly regarded thought leader in the area of healthcare IT standards, and is currently serving out his second year of a two-year term on the HIMSS Interoperability and Standards Committee Hans, thank you so much for joining us today to discuss healthcare IT standards maturity Health Information and Management Systems Society 1

2 Hans Buitendijk: Thank you, Joyce, for inviting me to talk with you on some of the challenges we face in determining how to best introduce new standards, and particularly implementation guides into the healthcare information technology industry to move interoperability forward. Thank you. So Hans, why is standards maturity such an important consideration for those in the health IT industry at this point? Standards maturity is really important because it is one of the barriers gating the speed and rate of standardization, which really moves the dowel closer to interoperability. We need to look at uptake and adoptional standards, especially as we move forward from voluntary adoption to coordinated, mandatory adoption for a number of interoperability standards in healthcare informatics. At this point, many of us are talking about what makes a standard mature enough to be adopted, at what stage do we move it forward for implementation, or when should we let the standard stay and incubate in a volunteer setting in order to shake out the box a little bit more. So that s really why we need to chat a little bit more about that. So what we re discussing with you today, and proposing to the listeners, are some really big questions. One is, when is a standard sufficiently mature, and when do we implement that standard to move interoperability to the next level? And the goal is that we re getting to a level where everybody is moving in lock-step, so the sender and receiver of the information know exactly what to expect, when to expect it, and what the data means along the way. So, in my understanding, this is the primary goal of interoperability that we re striving to achieve in health IT. You re right, Joyce, and we can only begin to address these big questions if we have a better understanding and agreement on what are the attributes of a mature enough standard, or, when a standard s considered baked. So I like the reference to baking. What would you consider to be some of the ingredients or attributes that make a standards more-or-less mature? Clearly there are some obvious ones, or seemingly obvious ones. Adoption and acceptance means including how many systems have implemented the standard and use it in ongoing operations. But that may be deceiving as well. We all know the saying that if you have seen one HL7 implementation, you have just seen one not all, as the absence of implementation guides yields much variation. And you could apply that statement to HL7 CDA as well CDA is the clinical document architecture. These base standards have a lot of ambiguity for implementers to make different choices to solve the same problem, so it is important to consider whether a foundation standard is widely adopted, or much more importantly, whether specific implementation guides are widely adopted. Another attribute would be something like, has the standard followed the progression from an initial draft to a normative standard? It may take several iterations before the right level of completeness has been achieved. For instance, the consolidated CDA, or C-CDA, is in its second major iteration. With a lot of use of 2014 Health Information and Management Systems Society 2

3 CDA revision 1.1, and thus a lot of real-world application and implementation experience, it is still considered to be DSTU and not fully mature. At the same time, HL7 s laboratory orders implementation guide is just in its first iteration, without any implementations yet, and this is also considered DSTU. Clearly, the consolidated CDA standard is further along in maturation and further along in its iterative process, but it still wouldn t be considered fully mature yet. To complicate this further, everybody s threshold for when a standard is good enough or mature enough, it varies. A metaphor to apply here would be the ripeness of bananas. Some people like to consume them when they re still a little bit green, some people prefer them yellow with no green, some may eat them when they re very ripe and may even have some bruising. In this example, when the brown spots and weaknesses cannot be cut from the banana, it is replaced with a new product. The analogy can be used to describe the various preferences of people in health IT for adopting standards at different levels of ripeness or maturity, as well, where not all the players in healthcare IT are ready or willing to take the next steps in standards implementation at the same time. Some are happy to start soon, some prefer to stay a little bit longer in development mode before jumping in. Sometimes those willing to become early adopters find that the standards proposed have not been roadtested enough, and they bear the brunt of the cost to work out the kinks in the middle of their implementation. On the other hand, when all or many of the parties involved in the healthcare IT interoperability game are mandated or forced to adopt standards that are not quite mature, we re all making the same mistakes. In this situation few, if any, of us are able to communicate due to different adoption interpretations, and this has not been a very efficient use of resources either. It would seem, then, that. if a few can work out the kinds and pass on this knowledge to others, uptake of the next steps towards interoperability would be a lot less painful for most. That sounds like great advice to me. One thing I wanted to further explain is the acronym DSTU you mentioned it a couple times, and just so our audience knows, that s draft standard for trial use. So it s saying that the standard is not fully mature yet. So, we ve talked about the face that there are different preferences for when a standards is, well let s say ripe or mature enough to be adopted. Is there a way to score or objectively measure maturity of health IT standards in some way? I don t think we have a clear agreement on how to measure maturity objectively yet. In the United States, the HIT Standards Committee which is the federal advisory committee to the Office of the National Coordinator for Health IT, or ONC they utilize a tool to get a sense of maturity by gathering impressions of maturity on the standard or specifications, looking at the maturity of underlying technology components, and analyzing market adoption. It plots against adoptability, the ease of implementation and deployment, the ease of operations and intellectual property so a number of different dimensions, and that s what they use based on feedback from their Committee members. Currently also, discussions are taking place within HL7 about how to map maturity using different dimensions, such as where is the standard in the standard s lifecycle? Is it informative? Is it DSTU? Is it 2014 Health Information and Management Systems Society 3

4 normative? Or perhaps how could it relate to something like a Gardner-Hype Cycle? Different dimensions and discussions are in place to figure that thing out as well. And additionally you should know, Joyce, the HIMSS I&S Committee last fall offered a white paper that focuses on evaluating HIT standards by comparing them to some key principles which support health IT interoperability in the United States. We, as I was one of the authors, offered a set of ten aspects that can provide insight as to whether a standard may be mature enough to adopt widely. So, for example, an aspect might be whether clear implementation guides have been defined, or whether pilots have been implemented, or whether beta testing has been there with testing tools starting in DSTU so a number of different factors to look at. In some ways, the HIMSS I&S Committee approaches just a more granular perspective on the maturity dimensions that the HIT Standards Committee utilizes, but overall, we don t quite have a clear tool yet that everybody can rally around. And while we do need to solve the interoperability problem, and there s an urgency to get standardization in health IT, in my opinion at least it s really about balancing the risk of adopting standards too soon and wasting resources, and waiting too long to implement and losing opportunities from increased healthcare interoperability. It s really a balance between those. If too soon, a lot of time and effort goes into fixing issues across a large number of organizations, and more resources are needed to invest in a process which is not quite efficient yet. On the other hand, if we wait too long until the standard is perfect, this does not move the needle of interoperability either, and certainly not quick enough and we missed the possible benefits of a better healthcare IT system. So therefore, to help us mitigate these risks, and in turn maximize the benefits and minimize the costs, it s really important to have clarity [on] an agreed-to and reasonable maturation process in order to introduce new standards in a predictable, manageable and ultimately successful fashion. So those are some excellent points, and I think it leads to your recommendation that a measurable standard maturation process be recommended or implemented. Can you share your thoughts on what you think the key steps in that process would be? Sure. A couple of the key steps in a formal maturation process would include asking whether or not there is a clear implementation guide. As I previously mentioned, it s important to eliminate ambiguity with implementation guides. Keith Boone, in an earlier I&S podcast, 1 explained the difference between the implementation guide or implementation profile compared to a standard, and pointed out that a guide or profile focused on a specific use case, applies the standards to that precise situation, and removes as much uncertainty and/or optionality in the implementation as possible. For example, in the case of the HL7 laboratory standards and implementation guides, they were developed in tandem. On the contrary, if only the underlying standard is available (HL7 version 2 or HL7 CDA), then we cannot guarantee that it will be deployed consistently across providers. Even though the standard may be considered mature, it s not fit to purpose for a specific use case, and it will not be easy to ensure consistent implementation across all HIT providers. There s still too much imprecision and flexibility in its implementation without these types of guidance documents, and we have a number of different areas where you can see good examples in IHE, in 1 Episode #4: What are health information technology (IT) standards? HIMSS Interoperability & Standards Podcast. October Health Information and Management Systems Society 4

5 HL7 see where these guides have been developed on top of existing foundational standards, so that s important. Another step would be whether the standard or guide has gone through consensus development and a thorough balloting process. Where is it in the process? Is it informative? Is it a Draft Standard for Trial Use or is it normative? Informative and DSTU, or Draft Standard for Trial Use guides, they re really not intended for wide use in the sense of, We have it fully baked. Rather, they have been issued to be deployed by a smaller group of interested parties, try it out, learn and make the necessary updates to fit it to the reality of the use case. Frequently, at times, it s that not until you deploy it into a real production environment will you know that it actually works. So, early in the process of developing and implementing a standard, the documentation can see many substantial changes and revisions to the materials, while later in the process the documentation starts to settle down, get more static. Fixes should be minor, and the focus is on expanding scope. Along the way, a formal review process allows for wider participation by stakeholders to ensure the guidance is fit for purpose. And while some of the terms I m using may very HL7-specific perhaps on account of the fact that that s where the majority of my standard works is taking place I ve also seen increased collaboration between HL7 and Integrating the Healthcare Enterprise, or IHE, and you are part of that, Joyce, and so I m in a lot of those activities. And the principles behind these concepts we are discussing are applied very similarly by both of these key health IT standards development organizations. In fact, these congruent efforts may pave the way for other SDOs looking to create fit-for-purpose standards implementation guides as well, or other organizations like the CDC. A third step would be the amount of use. Has it been adopted? Has it been tested and is it being used? And Joyce, you know very well that for the last 20 or so years, IHE has been a pioneer in testing and conformance efforts through the Connectathons. And if a guide has gone through a Connectathon, both the documentation and feasibility of the guide are tested, which often then leads to adjustments and improvements to eliminate ambiguity, ensuring conformance by multiple diverse entities. However, the benefits of testing such as is done through Connectathons does not stop there. Testing capabilities such as NIST s as in support of the certification program in the US they asked for substantial increased clarity and removed ambiguity as well, in both testing tools and in the guide itself, it really created more clear definitions. Preferably, this testing would involve implementers that were not part of the original development process, so that the standard or guide is validated by two impartial parties who can pick up the documentation, implement it, and then communicate successfully for that particular use case with minimal to no on-site tweaks. That s when a guide has matured enough to drive or move toward industry-wide adoption of the standard. And in terms of testing profiles and guides in a number of production environments, it is not a replacement for actual use, but it helps with the ease of implementation for the real case the standard and guide was intended to support. There is really a major focus on a process here, and I think you ve laid out those steps very, very nicely. Considering these steps as criteria for maturity, it seems like a number of standards that are currently in the EHR certification program in the US might not have made the cut. And if that s the case, how do we move forward with standards that have been mandated but really aren t fully mature? 2014 Health Information and Management Systems Society 5

6 Yeah, some argue that a number of standards have been prematurely mandated or proposed. So for example, the laboratory orders interface implementation guide, which we typically call the LOI IG, that was proposed for the 2015 edition, currently in NPRM awaiting further feedback. Or the lab results implementation guide, or shortly known as the LRI IG, and that already exists in the 2014 edition. Neither of these actually had any road-testing they were created, they were developed, and then they were put into either the rule, very quickly, or are being proposed to go into rule. One could even reasonably argue that consolidated CDA was not well road-tested, either, but on the other hand, we would not have been able to achieve the progress already made had we waited to begin implementing C-CDA. So it goes back to that balance. There is not an exact cut-off point it s a balancing act. But we cannot afford to have everybody pay the price for trying to adopt immature standards. Nor can we wait until everything is perfect. If we can make the considerations outline more transparent, allow for predictable and orderly progression from use case definition to testing to piloting to limited deployment to wide deployment while not skipping pilots and limited deployment we re on our way. We need to recognize that interoperability takes at least two to tango, and exponentially more as the number of exchange actors increases, as more partners are involved. So everybody needs to move at the same time, in lock step, and then we ll be able to move forward with confidence that we ll get there, knowing that Rome wasn t built in one day. That is definitely clear from your remarks, Hans, and it really strikes me that we re very fortunate to have your expertise involved with this work. Now my last question covers your professional and volunteer work on standards and their maturity. How can our listeners get involved with these efforts to advance interoperability in health IT? I m glad you asked, we could use some help. The HIMSS I&S Committee plans to continue its efforts to review standards against the evaluation principles it defined, and publish these reviews for the larger community. At the same point in time, IHE, HL7, X12, NCPDP to just name a few, and there are other organizations as well they will continue to develop and improve the guidance necessary to get to the level of interoperability we want to achieve. So people might want to consider joining HIMSS or any of those other organizations to help further this work and make interoperability happen better, and faster. Hans, thank you so much for sharing your insights, and for joining us today. I know all of our listeners will benefit from your thoughts on standards maturity, and your recommendations to advance interoperability. It has been my pleasure, and I very much appreciate you and HIMSS for inviting me to speak with you today on interoperability and standards that will lead us into real health information exchange. Thank you, we look forward to seeing the progress This concludes the podcast. To learn more about interoperability and standards activities at HIMSS, go to click on Browse by Topic under the HIMSS Resource Library, and link to Interoperability & Standards. Thank you for listening Health Information and Management Systems Society 6