|PCC has published updates to a couple of profiles for Trial Implementation. Take a read and see if these are a fit for your situation!|
Plentiful is the health IT industry with FHIR discussions and opportunities. It’s on everyone’s topic boards, it’s being pitched at all of the health IT conferences, it’s being discussed and used time and again in SDOs, apps are being developed, initiatives are born. And it’s possibly near a tipping point of success.
HL7/IHE History around FHIR
IHE and HL7 have a long history, going back to the beginning of IHE in 1998 (HL7 was already in existance). There have always been collaborators across and between the two organizations. This is, effectively, how IHE begun. A bunch of health IT standards geeks were seeking a new way to provide interoperability guidance to the world, and thus IHE was born. So it’s not surprising that pattern has continued into the era of FHIR. It started with ad-hoc liasons between the organizations, taking a set of FHIR resources into an IHE Profile, or taking requirements from an IHE Profile back to HL7 to create or modify an existing FHIR Resource. The value of FHIR was quickly recognized as a market disruptor, and as such IHE and HL7 begun to explore the idea of formal collaboration more seriously. These organizations are big ships, and they turn slowly, but over the past 6 years, they seem to be turning in the right direction.
In 2013 HL7 and IHE drafted and signed a Statement of Understanding to identify many areas of collaboration between the two organizations. While this SOU did not make specific mention of FHIR, I strongly suspect FHIR was a driving factor in the agreement.
In 2014 the IHE-HL7 Coordination Committee and the Healthcare Standards Integration (HSI) Workgroup were both created. The former in IHE, the latter in HL7. These were intended to be “sister groups” to work with each other helping to improve collaboration for both organizations, leading to greater efficiencies for all involved. These groups languished a bit and never really got enough traction to continue in the way they were originally envisioned.
A few years later, in 2017, IHE created and IHE FHIR Workgroup that continues to meet today. This workgroup is focused on how to include FHIR in IHE Profiles and has very detailed guidance on this documented on the IHE wiki. It also tracks IHE Profiles using FHIR, cross-referencing across IHE Domains. This workgroup has produced materials and guidance that is very helpful to bringing together IHE and FHIR.
In 2018 Project Gemini was launched, named after the space program of years ago. It’s goal is to identify and bring to market pilot project opportunities based on FHIR. It will leverage and potentially create specifications, participate in testing activities, and seek demonstration opportunities. Basically, it’s job is to tee up FHIR-based projects so they can be launch into the outerspace of the health IT ecosystem. Interoperability is often big, expensive, and scary to implementers and stakeholders – similiar to the challenges that NASA’s Project Gemini was facing.
We are on the cusp of pitching into a new era in health IT with the forthcoming of FHIR. While FHIR will not be a silver bullet, it does provide a great opportunity to be disruptive, in a good way.
IHE PCC and QRPH – Profiles on FHIR
The PCC and QRPH domains have been working on FHIR-based IHE Profiles since 2015. PCC has a total of 9 Profiles that include FHIR, and 1 National Extension, and is working on updating 1 of those Profiles this development cycle to include additional FHIR Resources. QRPH has a total of 4 Profiles leveraging FHIR, with 1 new FHIR-based Profile in the works for this development cycle.
One observation that we have made within PCC, and this is also being used in other domains, is the importance of retaining backwards compatability for our implementers by adding FHIR as an option to the menu. It is not a wholesale delete old and bring in new situation. In fact, if we followed that approach then standards would likely never be implemented en masse as they would always be changing. So an IHE Profile that uses CDA today, and that is under conseridation for FHIR will be asssed by the IHE committee to determine if it should add FHIR as another menu item, or perhaps a more drastic measure should be taken to deprecate the “old” technology.
This will obviously vary based on a number of factors, and that’s a topic for another post, but the point is that the default goal for improving existing IHE Profiles with FHIR is not to replace everything in that Profile with FHIR. Rather, it is to assess each situation and make a wise choice based on what’s best for all involved (vendor implementaters, stakeholders (patients and providers), testing bodies, governments, standards bodies). This does not mean that everyone is happy all the time, but all angles must be considered and consensus is desired.
Implementation of IHE and FHIR
FHIR is being implemented in various ways across the industry. There are two very significant initiatives happening right now that are well-positioned to launch FHIR into the outer space of health IT: CommonWell Health Alliance and Carequality. Both iniatives have been around for roughly the same amount of time (CommonWell 2013, Carequality 2015), and focus on the same general mission to improve data flow in support of improving patient health outcomes, but they take different approaches to get there. CommonWell provides a service that members leverage to query and retrieve data, whereas Carequality provides a framework, including a governance model to do this.
These are fundamentally different approaches but both are achieving great success. CommonWell touts upwards of 11,000 healthcare provider sites that are connected to their network. Carequality touts 1,700 hospitals, and 40,000 clinics leveraging their governance model to exchange data. These are big numbers, and both organizations are on a trajectory to continue increasing their connectivity. CommonWell already has FHIR fully embedded as an option is their platform, with the ability for a member to only leverage REST-based connectivity (most, if not all of which is based on FHIR) to fully participate in the Alliance’s network. Carequality currently has an open call for participation in newly forming FHIR Technical and Policy Workgroups to include FHIR as a main-line offering in their specifications.
Given that both of these initiatives have included IHE as part of their original implementation requirements, and that both are now including FHIR, and that both have signifincat implementation numbers – we have an exceptional opportunity to advance interoperability in ways that we have not been able to previous.
The world of interoperability is alive and well, despite constant setbacks (due mostly to non-technical things), and thanks in part to IHE and FHIR. Convergence is happening, both on the SDO front as well as in the implementation world. And I fully expect that convergence to continue.
The fall PCC, QRPH, and ITI technical committee meetings were held in Oak Brook in mid November, as usual. Unfortunately I was not able to attend the October planning committee meetings – neither in person or via telecommute due to other committments, however I was able to catch up with what is going on by attending in person for the November meetings. I attended mostly PCC, and sat in on a few QRPH sessions. Here is a quick update on PCC Activities.
In PCC we are going to have a quiet year, with only one profile work item, and this work item is to update an existing profile: Dynamic Care Team Managment (DCTM) to include some additional FHIR-based guidance. Tune in for the calls being scheduled now if you want to learn more.
As I understand it there has also been some discussion on CDA harminozation, but there are no formal CDA harmonization work efforts on PCC’s plate for this upcoming cycle. This is a topic that has been discussed in previous years, but only mediocre progress has been made. Perhaps with efforts like Project Gemini there is hope to re-ignite some of this work.
Change Proposal Work
PCC received a sizeable number of CPs last year (2017), and have been slowly working through processing these. This work will continue with the goal for this next work cycle to have all of these CPs closed out.
Based on a quick count here is our CP submission by year:
|Year||Number of CPs Submitted|
While 2017 was not our largest CP submission year, it is still significant. We have 13 CPs that remain in “Assigned” status, which means that someone is reviewing and finalizing for inclusion in a ballot. If those CPs make it to ballot and pass, then they will be incorporated into the appropriate published document (e.g., Technical Framwork, Profile, National Extension, Appendix).
PCC Committee Structure
The PCC Planning and PCC Technical committees have made a decision to combine into a single planning/technical committee, at least for the next work cycle. This is to streamline the work of PCC given the lower number of participants. Fortunately we do have 3 co-chairs (one of whom is acting more as a “co-chair emeritus”, providing expert guidance to our two new co-chairs.) This is completely within the bounds of the IHE Governance, so no issues on that front. In future years we may split back into separate planning and technical committees if appropriate.
PCC Publication Cycle
We also discussed, and are interested in the idea of supporting a year-round profile publication process. This is something that has been discussed in previous years, but due to high volume of profile publication (and other reasons) it has not yet been possible to achieve. ITI is also interested in this idea and has started a wiki page with a great deal of detail. I encourage you to read this and comment on the wiki page if you have additional ideas to include. As part of this effort IHE may also need to look at it’s back end publication processes and explore opportunities to move away from pdf-based publication.
PCC has it’s work items outlined for this upcoming cycle, and an opportunity to explore what a new/different publication cycle might look like. While there are not a great number of profiles being published this year (only one, in fact, and it’s “just an update” at that), this doesn’t necessarily signify distress for PCC, rather it could indicate the market is still working on catching up with many of the profiles that PCC has published over the past several years.
This is the third post in a series on the past, present and future of the IHE PCC domain. So what’s next? Lots of stuff! At our face to face meeting this past summer we held a strategy meeting to discuss what we are doing with our domain as we were in a place of needing such clarification. The results of that two or so hour long session were new vision and mission statements, and a set of shiny new strategic goals for our domain.
The vision of PCC is to continually improve patient outcomes through the use of technology connecting patients and their care providers across healthcare disciplines and care paths.
The mission of PCC is to develop and maintain interoperability profiles to support coordination of care for patients where care crosses providers, patient conditions and health concerns, or time.
The strategic goals of PCC, which are 3–5 years in length, are to focus on content, workflow and nursing.. These three goals originate out of the work we have been focused on for the past several years and so they are not new concepts to us. However we felt it important to document specifics items around these goals to ensure our path forward is clear.
PCC has had such a heavy focus on content over its lifetime, and naturally content standards and implementation guidance is changing along with the landscape of HIT. HL7 has recently produced the Consolidated CDA implementation guide, which directly competes with PCC content profiles. I am not convinced this was entirely intentional on HL7’s part, as the implementation guide itself is actually quite good and there are even a few references to PCC content templates within it. To be more specific, C-CDA replaces the family of HITSP implementation guides that all sit on top of PCC content templates, but C-CDA also has breaking changes to the existing PCC templates, and at the current time is US realm only. This last bit is a big challenge for many non-US implementers, and the reason why adoption and uptake of C-CDA has been primarily US focused vendors. Due to these recent events around content PCC feels that it should be proactive and engaged with HL7 to ensure that the responsibility to create and maintain content templates is shared between the two organizations.
So what roles do each play as it relates to content? I believe HL7 should continue to play the role of providing the framework aspect of content with a bit of guidance based on healthcare domain, so they would own how any given CDA section and CDA entry should be structured with minimal guidance on implementation details of those templates. PCC would own the more specific implementations of those artefacts based on specific clinical use cases. This would include extensions to the schema, value sets and optionality. This makes sense as HL7 has a lot of experience with vetting standards to ensure they are broadly adoptable, and IHE has a lot of experience working with stakeholders from a variety of medical disciplines and has a great process already in place (Connectathons) to test profiles.
Workflow has long been a focus of PCC but really only in piecemeal, which is the same approach many other IHE domains follow. By piecemeal I mean more focused inwardly on solving a clinical use cases that have been brought to our domain rather than taking a cross-domain approach. Yes we do have a few profiles that have crossed into other domains, but by and large we author those profiles within PCC and have not always actively engaged other domains in our efforts. I believe PCC is well positioned to expand outside of our domain and across to other IHE domains to bring together workflows that are realized in the real world but have yet to be well represented in the interoperability profiling space.
PCC has received several profile proposals this year (four to be exact) that came from other IHE domains. Those domains are Radiology and Patient Care Devices. So you can imagine our delight of this news after our recent strategy sessions which concluded this exact effort is something we should be working on. It seems to be confirmation in every way that we are moving in the right direction.
The Nursing Sub-committee of PCC was established in 2008 and has had decent participation over the years, however the uptake of work produced from this sector of PCC has not been strong. I believe this is primarily because the content profiles we have produced easily apply to both nursing and clinician/physician based content. The difference however, is primarily in the workflows, and workflow also happens to be one of our strategic goals. We have learned that nursing workflows are often times vastly different from their counterpart clinician/physician workflows. And so we are presented with an opportunity to provide better guidance in this space.
Overall PCC is in a great place right now, on the cusp of exploring new opportunities as the world of HIT and interoperability continues to mature and change. If you are interested in getting involved check out our wiki page here.
Today the PCC domain is in a place of discovering where it is we are going next. We have published a few dozen profiles over the past several years, many of which are content focused, but some of which also cover integration and workflow. As the HIT interoperability landscape evolves PCC must continually assess the work it is producing for validity in the marketplace. Specifically with the advent of HL7’s Consolidated CDA implementation guide we now have duplicate templates and a split in the market. PCC has many international stakeholders that continue to reference our templates, however most US based systems are focused first on C-CDA as it is core to the interoperability components of Meaningful Use Stage 2 compliance.
So how are we figuring this out? We are talking amongst ourselves first and foremost to better understand what our vision and mission is, what our core values are so we stay true to our purpose and role within IHE and the industry. Secondly we are talking with external organizations to ensure we align and/or harmonize our work efforts as appropriate, lest we find ourselves suffering from the Ostrich Effect.
To provide a little background (and expand on my previous post) we have created and published a total of 23 content profiles, 7 integration profiles, and 5 workflow profiles since 2005. This year we are publishing two profiles, one of which is new, the other is a re-write/update, and also a white paper. Our profiles are Multiple Content Views (MCV) and Reconciliation of Clinical Content and Care Providers (RECON). Our white paper is A Data Access Framework using IHE Profiles (DAF).
MCV provides guidance on how text in CDA documents may be tagged to achieve different rendering behaviors. For example, a patient does not necessarily need or want to see all of the details of their lab results, they may just want to simply know if the results are “good” or “bad.” MCV provides a mechanism upon which data can be presented to meet this requirement. However, in no way does MCV change, remove or exclude data from the CDA document itself – it is still intact, in the narrative text and/or in the structured entries. MCV is really focused only on rendering of the data, and the narrative text in CDA documents is what is primarily leveraged to achieve this end.
RECON was originally published in 2011, focusing on problems, medications, and allergies sections. Upon further assessment last year it was determined that we needed to make two adjustments to the existing RECON profile : provide an easier implementation path and expand to include additional sections of data. RECON is important to patient safety to ensure that the right data is available to the right person at the right time. Without reconciliation in any given clinical workflow pertinant data may exist across multiple documents or locations in the system and the care provider may not have time to find that data, and assemble in a way that is meaningful for appropriate care of the patient. For more detail see the use cases outlined in the RECON profile. This is especially true in an emergency situation where time is of the utmost importance.
The DAF white paper describes a framework by which IHE profiles can support multiple means of access through substitutable modules (IHE profiles). This work effort was brought to IHE via the US ONC, and is not so much an attempt to map out implementation guidance, but to explore how various IHE profiles could be implemented to create successful interoperability scenarios, based on various use cases and business requirements. This effort utilized a few different enterprise architecture frameworks to assist including:
- Reference Model of Open Distributed Processing (RM-ODP)
- Zachman Framework
- HL7 Standards Aware Interoperability Framework (SAIF)
We covered these new profiles, as well as other PCC topics on our annual domain update webinar this week. This webinar was recorded and will be available online soon at http://ihe.net/webinars/.
If you look at our work this year as well as last year you will see a pattern emerging that our focus is shifting away from straight templating of content, and more toward how that content is used in various systems and situations. I see this as a natural next step in the evolution of content-based standards. However our templates are still quite important to many non-US based stakeholders, and so IHE and HL7 are working together at the executive leadership level to resolve the issues around duplication of templates that exist today. My sincerest hope is that IHE PCC is able to remain in the content template guidance space as it is vitally important to working through content requirements for a number of international stakeholders.
As co-chair elections are around the corner it got me to thinking about where the Patient Care Coordination (PCC) domain has been, where we are today, and where we are going. We operate in such a fast changing world in health IT and if you blink your eyes you will miss opportunities to innovate and impact the future of health IT in a positive way. This will be a multi-part blog post that takes a look at the past, present and future of the PCC domain.
My first IHE Patient Care Coordination (PCC) meeting was early in 2007 at the first face to face meeting for writing profiles of that cycle. I was not only a green software engineer (more or less) but also completely new to the world of health IT. My involvement at that time was a whopping six months, and that six months was spent primarily working on a new login process for my company’s patient portal application. So much for bringing any clinical application development experience to the table. Fortunately I was surrounded by peers in IHE whose knowledge and experience far exceeded my own and I had the opportunity to learn from and lean on their expertise. My task was to help write an obstetric profile, one that was based on various paper standards in use. At the end of that summer we had published the Anteparum Summary (APS) content profile (now in Final Text). In addition to participating in creating the APS profile I also had the opportunity to implement this profile along with the family of ITI profiles for document exchange (XDS, PIX, ATNA, CT) within an HIE.
In the following years in PCC we continued working on several other profiles covering a broad range of clinical use cases, providing guidance on content as well as integration. My focus was specifically around obstetric profiles, focusing on the ante, intra and post partum phases of the birthing process. I switched companies and continued developing interoperability solutions for the next several years. Along the way my IHE PCC colleagues bestowed the honor upon me of co-chair of the technical committee. I did that for a couple of years, and it was then that I developed a much more complete understanding of the processes within IHE as well as the importance of and opportunity of this organization to influence the world of health IT and ultimately improve patient care and outcomes.
After one term I stepped down as technical co-chair due to workload constraints (my wife and I also were blessed with a total of four children from 2004 to 2011 so family was certainly a big part of my life, and still is). A year or so later one of my colleagues convinced me to run for PCC Planning Committee co-chair, I thought on it for about 30 minutes and accepted the nomination and was voted in. As we are moving into another year of the IHE development cycle co-chair elections are upon us once again and I intend to run for another term of PCC Planning co-chair. Should I have the honor of serving my domain for another two years, I intend to sail us in some slightly new directions, focusing more on workflow and a bit less on content (but certainly not excluding content!), but more on that later in a subsequent blog post.
From the inception of the PCC domain in 2005 until the present (2014), PCC has published upwards of 35 profiles and several white papers. It has largely filled a gap in the industry providing content template guidance that has been eagerly adopted by implementers as well as international programs and initiatives (e.g. Meaningful Use, epSOS, ASIP Sante). We are now at a juncture of figuring out where to go next. Content template guidance will likely be a part of our future, but we must also consider our role in the workflow space, and how we can help to improve patient outcomes by providing guidance on the use of standards around interoperability.
One of the challenges with reading and understanding how CDA templates link together in PCC is that we are continuing to create new content templates, and have several still in Public Comment or Trial Implementation state. This means that we have document, section and entry content templates in several different published documents instead of neatly wrapped up in a single technical framework document. A single technical framework document (volume 2) is the end goal, but we must eat this elephant one bite at a time and deal with the complexities that come with such a task. Basically templates can be documented in one of 3 places: PCC Technical Framework Volume 2 (hereafter referred to as PCC-TF–2), CDA Content Modules Supplement, or profile supplements to the PCC-TF–2. Where templates are documented depends on their current state in the IHE development and publication process: Public Comment, Trial Implementation or Final Text. So yes, it is a bit confusing to navigate at first, but once you understand the makeup it is actually fairly straightforward. First let us cover these 3 locations, then we will talk about specifics of the types of templates and where each might be found.
PCC Technical Framework Volume 2
This contains all templates that are in Final Text state. That is, those templates that have been released into production. It is certainly possible that document templates in profile supplements may reference templates here.
CDA Content Modules Supplement
This is a holding tank for section and entry templates that are in the Public Comment or Trial Implementation state. PCC created this document several years ago to accomodate the need to share templates in draft state (Public Comment or Trial Implementation) across and between various profile supplements. At the time we had a lot of duplication across profile supplements and it quickly became very complicated to manage so this was a nice change. As it turned out this also became a great tool for other IHE domains to use as well. The QRPH domain has several templates in this same published document.
New IHE profiles are written initially as supplements to the Final Text version of the technical framework. This was intentionally designed in this way so that profiles must go through a period of implementation and testing to determine if they are ready to be released into the wild, which in IHE is defined as Final Text. More information on the process can be found on the IHE wiki. Getting back to the topic at hand, only document content templates will be found in profile supplements. Those document templates will reference section and/or entry templates that will be found in either the PCC-TF–2 or CDA Content Modules. So now that you understand a bit about where templates can be found here is a quick breakdown of the different types of templates that are found in these locations.
Document templates contain a list of section (and sometimes entry) templates and are identified by a name and a LOINC code. Document templates may be found in either the PCC-TF–2 or in profile supplements.
Section templates may contain other sections or entries, or both. These templates may be found in either the PCC-TF–2 or the CDA Content Modules Supplement, however are typically not found in profile supplements.
Entry templates are essentially the same as Section templates, in that they may be found in PCC-TF–2 or CDA Content Modules, but typically not in profile supplements.
In summary consider the matrix below that shows where each type of template may be found. Note the the PCC-TF–2 is the only location where all three are found, and this makes sense as the ultimate goal is to roll everything into the technical framework.
Finding a Template
To find a particular template of interest the best way is to look in the table of contents in the appropriate document, alternately one could search by name, or better yet by the template identifier. Every template in PCC (as well as other domains) is assigned a unique template identifier. The registry for these templates is available on the wiki, however these template identifiers also appear in the three document locations covered in this post (reference above matrix for which ones appear in which document). So while searching by name will get you most of the way there, searching by the unique template identifier is gaurenteed an exact match.
This revised approach of template management has certainly helped PCC (and QRPH) to manage the influx of new templates over the past several years, with the trade-off that finding the template you are looking for takes a bit of understanding of where to look. Hopefully this post fills in some of the gaps for folks who need it.