Posts by :
- Documents are ginormous (a very technical term).
- We cannot find what we need.
- It’s just a CCD – where’s the narrative?
- Where is the operative note?
- And more…
Across the Healthcare IT industry, from providers to software developers, and even into the U.S. Senate, we continue to hear that the content of shared Consolidated CDA (C-CDA) documents, in spite of improved guides and constraints, are not meaningfully useful.
There continues to be wide divergence of documents across the vendor and provider communities. For example we have heard:
In prior Allscripts posts we touched on many of these points, such as in the Relevant and Pertinent survey post. Results from this survey will be published soon. However, we now have another opportunity to help improve the content of C-CDA using a new scoring tool for C-CDA R2.1, the version of content that will be coming from 2015 Certified EHR products.
SITE C-CDA R2.1 Scorecard
The SITE C-CDA R2.1 Scorecard is a new opportunity to measure, in a repeatable manner, the quality of shared C-CDA content, and then use feedback to hopefully produce better and more meaningful content. We encourage customers, users and solution designers to use this mechanism as a way to find opportunities for improvement, both big and small.
The Office of the National Coordinator (ONC) and HL7 have been working together to leverage previous work on improving C-CDA content, based on the SMART (Substitutable Medical Apps Reusable Technologies) concept. Allscripts participated in the SMART C-CDA R1.1 project, along with several other EHR vendors. Allscripts submitted many 2012 Certified C-CDA documents, and internally we benefitted from the scoring exercise. Following up on this early work, a group of HL7 Structured Document participants reviewed and updated the rules and heuristics used for scoring content.
Soon, C-CDA R2.1 documents from 2015 Certified EHR products will be available, so consider submitting their content to the new SITE C-CDA R2.1 Scorecard to help ONC and HL7 improve the rules, and to help the industry as a whole improve the content that we share. For example, a submitted document might only get a score of a “C” in a particular section because something meaningful is missing. Providing that feedback to the system or vendor producing the document should result in updated content in a future release, and an overall better user experience in the future.
One very important note, and the following comes directly from the announcement of the Scorecard: do not include any Protected Health Information (PHI) or Personally Identifiable Information (PII) in your C-CDA file submissions to the Scorecard. Click here for more information on how to de-identify PHI.
You may send your suggestions or questions on content:
Happy Scoring! And note, we’re not proposing that every document always score an “A.” Our goal and responsibility is to raise awareness about the opportunity to produce more consistently usable documents.
A final thought for wishful thinking: shouldn’t we have content scoring that works for C-CDA, FHIR and the next new shiny object that comes along? Perhaps we, as an industry, learn enough from this project that is focused on C-CDA to take it to the next logical step where the Learning Health System scores content for relevance and importance as data are collected.
Update Aug. 18, 2016:
We want to make sure everyone understands that the SITE Scorecard is specifically examining and scoring for: “…whether the C-CDA document meets the requirements of the 2015 Edition Health IT Certification for Transitions of Care 170.315(b)(1) criteria.”
Use of C-CDA R2.1 documents is required. These documents for 2015 Certification testing will be forthcoming from Allscripts products according to the specific product schedules.
Editor’s note – Learn the basics in A beginner’s guide to FHIR. The article below answers additional frequently asked questions about FHIR.
Clients are asking good questions about FHIR and what it means for them. Here are a few that we’ve received about the emerging interoperability standard:
How does FHIR relate to the API requirement for 2015 certification?
To achieve 2015 certification, the Office of the National Coordinator for Health Information Technology (ONC) requires EHRs to be able to retrieve patient data using APIs. ONC did not specify FHIR as a requirement for the API certification, categorizing FHIR in the 2016 Draft Interoperability Standards Advisory as piloted with low adoption. However, ONC’s documentation reflects FHIR in its phrasing and direction, so it’s clear that ONC is generally supportive of the evolving standard.
How do FHIR Resources compare to Clinical Document Architecture?
The HL7 Clinical Document Architecture (CDA) is an interoperable content standard to help organizations exchange clinical data. CDA takes a document approach, providing the ability to group related content about the patient into a single document format.
In contrast, FHIR presents discrete elements of information – individual lab results, demographic information, medications and more – as data representations called Resources. An excellent overview is the Summary Introduction to HL7 FHIR. We can still aggregate information into larger constructs, similar to documents, using the Composition FHIR Resource.
What happens at an HL7 FHIR Connectathon?
FHIR Connectathons are hands-on collaborative coding sessions for developers that usually take place over the course of a weekend. These events have been growing in attendance over the last few years, attracting about 125 people at the most recent event in January 2016.
Before the event, HL7 proposes functionalities that the industry may want to implement as FHIR Connectathon Tracks. For example, this year the clinical track looked at clinical decision support. On Saturday, participants work on their projects, and on Sunday they have an opportunity to demonstrate their final product to the group.
Anyone who is a member of HL7 is welcome to participate or just to observe. FHIR Connectathons draw people from across the industry, including EHR vendors, insurance companies and client application developers. FHIR architects and subject matter experts also attend.
Is FHIR really the future of interoperability?
In a recent Forbes article, several industry experts debated the pros and cons of FHIR. FHIR is a promising standard for discrete data access to EHRs’ common clinical data set. Other methods, such as HL7 v2 or Direct Project, may be better suited to solve other interoperability requirements. We’re encouraged by the industry’s continued progress with interoperability through these approaches.
Does Allscripts offer FHIR support for SMART devices?
SMART, an open-standards API, started about six years ago as a private-sector attempt to help developing applications to connect with EHRs. Recently the API has expanded so application vendors can also use FHIR, and we’re talking with these vendors about testing SMART on FHIR applications on our service.
Can I test FHIR with Allscripts?
Allscripts is currently a member of the Argonaut Implementation program. As part of this program we’re building and testing an API service that will support FHIR queries and resources. We expect to share more about client access and application developer access in 2016. A version of Allscripts FHIR services is being used now at HL7 FHIR Connectathons.
Where can I learn more at HIMSS 2016?
At HIMSS (Booth #2612), Allscripts subject matter experts will be available to discuss our plans for supporting FHIR and demonstrate our FHIR API service and its interoperability with Allscripts EHRs.
Also, as part of a symposium before HIMSS Annual Conference, Allscripts Senior Vice President Rich Elmore will co-lead a discussion with experts about the potential solutions to interoperability, such as FHIR and public API approaches enabling SMART applications.
Have other questions about FHIR? Ask them in the comments below.
Interest in FHIR (Fast Healthcare Interoperability Resources) is growing as the standard for exchanging healthcare information takes shape. What is it and what will it mean for healthcare providers? Here are some frequently asked questions and answers:
Q. What is FHIR?
A. FHIR (pronounced “fire”) is a newly emerging international specification that standardizes the exchange of electronic healthcare information. First sponsored by Health Level Seven International (HL7) in 2011, FHIR incorporates the best features from previously developed standards.
Q. How is FHIR different from other interoperability standards?
A. The major difference between FHIR and other standards is simplicity and flexibility. Fast – the F in FHIR – expresses the intent to make this standard faster to learn, develop and implement.
Essentially, each application of the FHIR standard requires a resource approach to the information model (e.g., Medication, Procedure, or Immunization), which is more granular than other standards. Systems can use those FHIR Resources to then create commonly used content groupings that we see today, such as lists and documents. It is flexible and can enable faster and easier implementations.
FHIR supports four information exchange paradigms, most notably REST, the software architectural style that forms the basis for the World Wide Web. This approach aligns FHIR development more closely to other Internet development efforts outside of health care.
FHIR’s flexibility also means it will work across the entire spectrum of health care – from an orthopedic surgeon in Urbandale, Iowa, U.S.A. to a pediatrician in the heart of London.
Q. What is the current status of FHIR?
A. FHIR is currently a Draft Standard for Trial Use (DSTU2). The Office of the National Coordinator (ONC) 2016 Interoperability Standards Advisory lists FHIR as a Draft Standard, with Piloted Implementation Maturity, Low Adoption (less than 20%), Free Standard, with no currently available test tool to evaluate conformance.
Essentially, we expect to see Implementation Maturity, Adoption, and Test Tool development accelerate rapidly in 2016. FHIR is expected to be final in 2017.
Q. What is the Argonaut Project’s role with FHIR?
A. The Argonaut Project is a group of volunteer healthcare providers, health IT companies and universities working together to test the interoperability of FHIR implementations and profiles. Think of it this way: FHIR defines what can be sent, and Argonaut defines what must be sent. One of the strengths of FHIR is that the healthcare community is defining how to use it and what works best for the community’s needs.
Argonaut phase one focused on both data and document queries in support of U.S. Realm requirements, mostly as expressed by the Common Clinical Data Set. Phase two has continued with a focus on security for cross-enterprise authentication.
Q. What is Allscripts doing with FHIR?
A. Allscripts supports the ongoing work with the development of this new standard and participates in the Argonaut Project testing workgroup, HL7 Working Groups and Connectathons. We’ve completed initial development of a web service that will enable user applications to request and receive clinical data using FHIR. We’ll also attend the HL7 working group meeting, January 10-15, 2016.
Because we’ve written our own Open application programming interfaces (APIs), we have extensive experience addressing interoperability challenges across multiple systems. Having this set of robust, commercially proven APIs will make it easier for us to help our clients succeed with FHIR and interoperability more broadly.
Q. What should healthcare providers be doing to prepare for FHIR?
A. Preparing for FHIR is more of a technical issue for health IT companies to incorporate and test, so there are no immediate action steps providers need to be doing. Of course, healthcare providers should already be working towards meeting requirements aimed at improving interoperability, such as Meaningful Use Stage 3 and the 2015 Certification API requirements, which will likely be tied to FHIR in future versions.
FHIR is an exciting standard that we believe will become widely adopted. It is a logical next step along the path Allscripts started in 2007 with our own Open API, and we look forward to taking working with others in the industry to keep the progress happening.
George Cole update on Jan. 25, 2016:
This blog post has “kindled” a lot of reader interest. (Sorry, but in the technical geeky world, bad FHIR puns are encouraged.) Our team is working on a follow-up article, with more answers to frequently asked questions about what Allscripts is working on, how it relates to some of the 2015 Certification requirements and more. Be sure to comment here with your questions so we are certain that we cover the breadth of reader interest in FHIR.
Would you like to receive Allscripts blog updates by email? Subscribe here.
Clinical Exchange Document (CED)™ is a term we use at Allscripts to cover the multitude of standards-based, XML-format documents that are interoperable in healthcare exchanges. To improve their “meaningful usefulness,” the HL7 Structured Document Workgroup launched a short survey, which will gather feedback from providers about what data is most relevant and pertinent to them.
Widespread use and variation of CED
With Meaningful Use, providers have used CED (in the form of C-CDA) more frequently to exchange content between healthcare sites and providers. The Certification Rules have called out different HL7 Implementation Guides for use, such as Transitions of Care, Data Portability and View Download and Transmit. With each iteration of these Implementation Guides, the industry moves closer to constructing content that is semantically interoperable.
However, we continue to hear that these documents, in spite of improved guides and constraints, are not meaningfully useful. There continues to be wide divergence of documents across the vendor and provider communities. Additionally, there has been much testimony to various professional societies and technical groups, and even the U.S. Congress, about issues with CED content. For example, we have heard:
- Documents are ginormous (a very technical term).
- We cannot find what we need.
- It’s just a CCD – where’s the narrative?
- Where is the operative note?
And the list goes on from there.
Be heard: What content do you consider relevant and pertinent?
The HL7 Structured Document Workgroup recently launched a short survey to collect, analyze and report on what data providers find to be relevant and pertinent. The survey takes into account that there are varying degrees of relevance based upon practices, patient acuity, workflow and a number of other factors.
The survey also is trying to help us in the engineering and information-technology domain understand how systems might algorithmically select this content when a system generates CED – to date, an elusive goal.
The survey is meant for providers – not technical or information-technology people – because we’d like to hear from all who practice the delivery of health care. If you want to read more about the project please visit the HL7 Structured Document Relevant and Pertinent project page.
The survey is open through the end of November. We expect to be able to share data analysis and publish results in May of 2016.
Last week I went to IHE North American (NA) Connectathon, the health IT industry’s largest face-to-face testing event. We used real-world data in real-time to test national and international interoperability standards.
It takes countless hours of preparation just to get to the Connectathon. We completed the typical product development and quality cycles, plus hours of testing beforehand, just to qualify for participation in the event. During the Connectathon we spend long hours testing interoperability between different vendor systems.
Day 1 is always interesting as networks and configurations are not always as expected. Flexibility and patience were watch words for the day. Day 2 showed great progress, as always happens with Day 2, as all vendors seemed to have settled their network and configuration issues. Day 3 saw all vendors making great progress, and actually completing tests for verification faster than the monitors could evaluate the results.
Our interoperability focus at 2013 Connectathon
Allscripts sent three systems to Connectathon this year: Enterprise EHRTM 11.4.1, Professional EHRTM 13.0 and Sunrise Clinical ManagerTM 6.0. Much of our focus this year is on Meaningful Use Stage 2 (MU 2) and Referral Workflow:
- Consolidated CDA – the new specification of 9 Clinical Exchange Document formats. The Allscripts Community Library allows the EHR products to easily produce documents that meet the requirements for MU 2, according to the Consolidated CDA implementation guide.
- Healthcare Provider Directory (HPD) – allows healthcare providers to find names and Direct addressing information for providers to whom they refer. The Provider Directory Query enables them to find the information, regardless of whether or not it is an Allscripts-to-Allscripts referral.
- Multi-document submission sets –allows many documents relating to the same referral or instance of care to be submitted together inside one envelope.
- Cross-enterprise User Assertion (XUA) – allows one system to package and send claims about the currently logged-in user so other systems may make business decisions about the user’s level of access to data. XUA is an important part of the Nationwide Healthcare Information Network (NwHIN), as well as the research and clinical trials domain for disease reporting, quality control and new drug studies.
Our Community Solutions group develops these profiles, plus the work on Consolidated CDA, which are available to all Allscripts applications. In addition to these new profiles, we also tested the typical community transactions.
Each year our systems have expanded the set of IHE Profiles to test, based upon the needs of the community to support interoperability. Because of our work on standards- based interoperability in past years, we can publish a Success Stories paper at the HIMSS Interoperability Showcase with references to live client implementations.
We will publish Connectathon results when they are available, and all applications will be publishing new IHE Integration Statements to the IHE Product Registry. On to the HIMSS Interoperability Showcase! Be sure to visit us there.