Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

How Open mHealth Designed a Popular Standard (Part 3 of 3)

Posted on December 3, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first section of this article introduced the common schemas for mobile health designed by Open mHealth, and the second section covered the first two design principles driving their schemas. We’ll finish off the design principles in this section.

Balancing permissiveness and constraints

Here, the ideal is to get accurate measurements to the precision needed by users and researchers. But many devices are known to give fuzzy results, or results that are internally consistent but out of line with absolute measurements.

The goal adopted by Open mHealth is to firm up the things that are simple to get right and also critical to accuracy, such as units of measurement discussed earlier. They also require care in reporting the time interval that a measurement covers: day, week, month. There’s no excuse if you add up the walks recorded for the day and the sum doesn’t match the total steps that the device reports for that day.

Some participants suggested putting in checks, such as whether the BMI is wildly out of range. The problem (in terms of public health as well as technology) is that there are often outlier cases in health care, and the range of what’s a “normal” BMI can change. The concept of a maximum BMI is therefore too strict and ultimately unhelpful.

Designing for data liquidity

Provenance is the big challenge here: where does data come from, how was it collected, and what algorithm was used to manipulate it? Open mHealth expects data to go far and wide among researchers and solution providers, so the schema must keep a trail of all the things done to it from its origin.

Dr. Sim said the ecosystem is not yet ready to ensure quality. For instance, a small error introduced at each step of data collection and processing can add up to a yawning gap between the reported measure and the truth. This can make a difference not only to researchers, but to the device’s consumers. Think, for instance, of a payer basing the consumer’s insurance premium on analytics performed on data from the device over time.

Alignment with clinical data standards

Electronic health records are starting to accept medical device data. Eventually, all EHRs will need to do this so that monitoring and connected health can become mainstream. Open mHealth adopted widespread medical ontologies such as SNOMED, which may seem like an obvious choice but is not at all what the devices do. Luckily, Open mHealth’s schemas come pre-labelled with appropriate terminology codes, so device developers don’t need to get into the painful weeds of medical coding.

Modeling of Time

A seemingly simple matter, time is quite challenging. The Open mHealth schema can represent both points in time and time intervals. There are still subtleties that must be handled properly, as when a measurement for one day is reported on the next day because the device was offline. These concerns feed into provenance, discussed under “Designing for data liquidity.”

Preliminary adoption is looking good. The schema will certainly evolve, hopefully allowing for diversity while not splintering into incompatible standards. This is the same balance that FHIR must strike under much more difficult circumstances. From a distance, it appears like Open mHealth, by keeping a clear eye on the goal and a firm hand on the development process, have avoided some of the pitfalls that the FHIR team has encountered.

A Mature API for an Electronic Health Record: the OpenMRS Process

Posted on August 14, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

By some measures, OpenMRS may be the most successful of the open source EHRs, widely deployed around the world. It also has a long experience with its API, which has been developed and refined over the last several years. I talked to OpenMRS developer Wyclif Luyima recently and looked at OpenMRS’s REST API documentation to see what the API offers.
Read more..

Healthcare Standards – Opportunities and Challenges Remain for SNOMED CT, RxNorm and LOINC

Posted on October 22, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

The following is a guest blog post by Brian Levy, MD, Senior Vice President and Chief Medical Officer for Health Language.
Levy Low Res

Health IT standards and interoperability go hand-in-hand. Going forward, the success of the industry’s movement towards greater health information exchange (HIE) will hinge on the successful uptake and adoption of standards that will ensure reliable communication between disparate systems.

Progress is being made in this area through both messaging and coding standards introduced as part of Meaningful Use (MU). Specifically, MU coding standards that draw on such industry-respected clinical vocabularies as RxNorm, SNOMED CT® and LOINC® have the potential to drive more accurate, detailed sharing of patient information to promote better decision-making and patient outcomes.

Effectively deploying and adopting these standards is a huge undertaking with responsibilities falling to both vendors and providers going forward. To survive in future of healthcare, EMR vendors will have to evolve to support current and future industry standards. Providers will also have to grow their knowledge base and become more aware of how standards impact care delivery—instead of simply relying on vendors to pick up the slack.

The ability to “normalize” data to support all of these standards will be critical to advancing interoperability and communication between healthcare providers. With so many federal health IT initiatives competing for resources, the integration and use of terminology management solutions will become an important element to any data normalization strategy.

As providers assess their current needs and vendors move towards more enhanced offerings to align with new standards, the combined effort should produce significant progress towards improved information sharing. In the meantime, many challenges and opportunities exist along the roadmap to full implementation and adoption.

Vendor Readiness

While the EMR vendor market hit $20 billion in 2012, recent surveys suggest that many will not have staying power for Stage 3 MU. And one of the primary reasons, according to a 2013 Black Book Market Research report, is lack of focus on usability. An earlier report also pointed to 2013 as the “year of the great EHR switch,” pointing to provider frustrations that their current EMRs do not address the complex connectivity and sophisticated interface requirements of the evolving regulatory landscape.

Stage 1 MU created an artificial opportunity for many vendors to enter the market through government incentive grants. Because most initial EMR systems were not designed with Stage 2 requirements for HIE standards in mind, many vendors may find that they are not in a position to fund the infrastructure advancements needed to support future interoperability.

For instance, many EMRs support ICD-9 or free text for the development of problem lists. Under Stage 2 MU, problem lists must now be built electronically using SNOMED CT, requiring EMR vendors to develop and put out new releases to support the conversion. In tandem with this requirement, EMRs will also have to be designed to support RxNorm and LOINC.

It’s a time of upheaval and financial investment in the EHR industry, and when the dust settles, healthcare providers will have designated the winners. The end-result will ultimately include those players that can support the long-term goals of industry interoperability movements.

Minimizing Workflow Impacts

In existence since 1965, the SNOMED CT code set has a long track record of success and international respect. A comprehensive hierarchical system that includes mappings to other industry terminology standards, the code set enables computers to understand medical language and act on it by organizing concepts into multiple levels of granularity.

Few would dispute the potential of SNOMED CT to enhance accuracy and address the detail needed to promote enhanced documentation practices, but the expansive nature of the code set is still not exhaustive. Searching and finding the SNOMED concepts to include in Problem lists often requires further expansion of synonyms and colloquial expressions commonly used in clinical practice.  In addition, an accurate SNOMED code may not equate to a billable ICD-10 code, potentially requiring clinicians to conduct multiple searches if EMR workflow is not carefully planned.

The challenge for healthcare organizations is two-fold when it comes to the complicated SNOMED CT conversion process. First, the conversion represents one more complex IT project that healthcare organizations must undertake  amid so many other competing initiatives. Second, the success of implementations will be diminished if clinician workflows are negatively impacted. With EMR documentation practices already requiring more time from a clinician’s day, the situation will only be exacerbated if multiple code searches are required to ensure regulatory compliance for MU and ICD-10.

Terminology conversion tools that leverage provider-friendly language can be a great asset to easing the burden by providing maps between ICD-9 or ICD-10 and SNOMED CT problems. Physicians search for the terms they are accustomed to using in the paper record, and terminology tools convert the terms to the best SNOMED CT and ICD-10 codes behind the scenes.

For example, a clinician may add fracture of femur to a problem list, but ICD-10 requires documentation of whether the fracture was open or closed, the laterality of the fracture and whether the fracture was healing. Provider-friendly terminology tools provide prompts for the additional elements needed and guide clinicians to the most appropriate choices without the need for multiple searches.

Improving Mapping Strategies Internally and Externally

Industry crosswalks and maps exist to help ease the transition to new standards like SNOMED CT, RxNorm and LOINC. While these tools provide a good starting point in most cases, there is simply not a gold standard map that will work for every case.

Consider RxNorm, a naming system that supports semantic interoperability between drug terminologies and pharmacy knowledge base systems. Working in tandem with SNOMED CT to improve accurate capture of patient information from external systems, RxNorm codes are now required as part of the CCD (Continuity of Care Document) and HL7 messages for capture of medication information.

While designing EHRs with the capability to send and receive RxNorm codes is the first step, healthcare providers will still require a method of converting codes from RxNorm to internal medicine systems and drug information and interactions databases like Medi-Span, First Databank, Micromedex and Multum. Another challenge to standardizing medication information is the use of free text. Many healthcare providers receive drug information that is not coded at all, requiring a specific, customized mapping.

LOINC, a universal standard for identifying medical laboratory observations, is particularly challenging in this arena. Because the industry is home to hundreds of local lab systems and thousands of local lab codes, creating a single industry mapping solution is nearly impossible. The process often requires that sophisticated algorithms be built by performing an analysis of individual lab tests that are conducted in a particular hospital.

By leveraging the expertise and sophistication of a terminology management solution, healthcare providers can more easily automate and customize mapping of patient data to standardized terminologies. Otherwise, IT departments must expend valuable staff time to build complex mapping systems to address the myriad of needs associated with an influx of new standards.

Conclusion

The healthcare industry has identified use of a common medical language as a key foundational component to advancing information sharing capabilities. By designating such standards as SNOMED CT, RxNorm and LOINC as MU requirements going forward, the industry is taking a progressive step forward to ensuring clinicians have more efficient access to better patient information.

It’s a critical step in the right direction, but the road to success is complex. Healthcare organizations that draw on the expertise of terminology management solutions will be able to achieve the end-goals of this movement much quicker and with fewer headaches than those trying to implement these complex standards on their own.

Laying the Best Foundation for Medication Reconciliation

Posted on September 6, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

The following is a guest blog post by Brian Levy, MD, Senior Vice President and Chief Medical Officer for Health Language.
Levy Low Res
Effective medication reconciliation across the continuum of care is a critical element to eliminating medication errors and adverse drug events (ADEs). It is a focal point of such national initiatives as Meaningful Use (MU) and the Joint Commission’s National Patient Safety Goals and will also be crucial to ensuring performance metrics are met under Value-Based Purchasing and the Hospital Readmissions Reduction Program.

Simply put, one of the primary end-goals of current industry movements is to eliminate the revolving door effect in healthcare where patients are readmitted soon after discharge due to ADEs or lack of good information across the continuum. A growing body of research points to enhanced medication reconciliation as an effective way for hospitals to reduce readmission rates to meet this objective.

A 2012 study published in the Joint Commission Journal on Quality and Patient Safety found that accurate preadmission medication lists—acquired as part of medication reconciliation strategies— reduced ADEs both in the hospital and following discharge. Another paper published in the November 2012 edition of Pharmacotherapy also points to the critical role ADEs play in readmission rates and how ineffective care transitions, especially as they relate to medication management, exacerbate the situation.

The logistics of medication reconciliation has historically been an uphill battle for many clinicians. Without an electronic method for capturing information, the scene usually comes down to a Q&A session where physicians, nurses or other clinicians rely on patients to give them an accurate medication list. When a patient is unaware of the name of a medication, it usually results in a protracted delay in patient care while phone calls are made and consults conducted to accurately identify medications and avoid the potential for error.

EHRs provide the first step to correcting this inefficient way of gathering information. And while these systems are great repositories of patient information, the difficulty for medication reconciliation has been a lack of standards—specifically the lack of a standardized medical vocabulary. A number of proprietary medical terminologies exist within the industry, and without a standard for information exchange, the risk is that one drug could be identified by a number of different terminology codes depending on the proprietary system used.

Clinicians need an effective method for exchanging patient medication information between disparate systems in a standardized format that can be translated accurately by various healthcare organizations, providers and departments involved in patient care. MU is addressing this issue on one level through the introduction of RxNorm, a normalized naming system produced by the National Library of Medicine for generic and branded drugs and a tool that supports semantic interoperability between drug terminologies and pharmacy knowledge base systems.

RxNorm is a critical first step to ensuring the feasibility of building and accessing an accurate medication summary, thus minimizing the possibility of duplicate therapies, drug allergies and drug interactions. By adopting this standard, healthcare organizations and providers will begin receiving RxNorm codes in important CCD summary of care documents and HL7 messages. This standard will complement the use of the Systematized Nomenclature Of Medicine Clinical Terms (SNOMED CT®), a widely-used clinical terminology set also required under MU for the creation of problem lists.

While RxNorm provides efficient and accurate capture of medication information from external systems, healthcare organizations and providers will still require a method of converting codes from RxNorm to internal systems and visa-versa. This step ensures that internal medicine systems and drug information and interactions databases like Medi-Span, First Databank, Micromedex and Multum can also reconcile important patient medication information.

To address the full picture of data normalization, healthcare providers can leverage a healthcare terminology management solution to ensure automated mapping of patient medication data received from disparate sources to standardized terminologies. This process de-duplicates data, creating a normalized code across all clinical systems used internally, minimizing the potential for error.

This approach also provides an effective way for leveraging a comprehensive, longitudinal patient record, which is a primary goal of the health IT movement to enhance patient care. A foundation of standardized codes enables healthcare organizations to more fully develop advanced clinical decision support functions, where alerts can be received immediately for clinical activity impacting individual patients or within populations of patients.

As the healthcare’s industry move toward higher-quality care and more efficient care delivery continues to mature, the use of standardized medical terminologies will be paramount to effective clinical information exchange. While some initiatives like RxNorm and SNOMED CT are addressing this need for standardization, healthcare organizations can further advance data normalization strategies by leveraging the efficiencies and advantages of healthcare terminology management solutions.

Information on CCR, CCD and EMR

Posted on November 4, 2009 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Dr. Jeff sent me the following summary of quotes he put together about CCR and CCD and how they relate to EMR. I don’t think he meant for it to be published, but the information was too good not to publish it. So, sorry that it’s missing references to where the quotes were made and is a little scattered. With that said, take the following quotes as information purposes and I’d be happy to update the source if someone knows where it’s from. I think Dr. Jeff is going to find some of the sources as well. Enjoy!

“The Continuity of Care Record (CCR) is a patient health summary standard.  It is a way to create flexible documents that contain the most relevant and timely core health information about a patient, and to send these electronically from one care giver to the next” – Wikipedia

XML(Extensible Markup Language) is an open standard for structuring information. – the standard data exchange interchange language used by the CCR

PDF and Office Open XML – other formats that the CCR uses

“Because it is expressed in the standard data interchange language known as XML, a CCR can potentially be created, read and interpreted by any EHR or EMR software application” – Brian Klepper

CDA(Clinical Document Architecture) stores or moves clinical documents between medical systems. Documents are things like discharge summaries, progress notes, history and physical reports, prior lab results, etc. The CDA uses XML for encoding of the documents and breaks down the document in generic, unnamed, and non-templated sections.

The CCR Standard was developed by a collaborative – the Massachusetts Medical Society (MMS), the HIMSS (HIMSS), the American Academy of Family Physicians (AAFP), the American Academy of Pediatrics (AAP), and other health informatics vendors – under the auspices of ASTM International, a not-for-profit organization that developes standards for many industries, including avionics, petroleum, and air and water quality” – Brian Klepper

“The CCR’s advance will allow patient health data to be easily transported from one platform to another, intact and with integrity, so that better decisions can positively impact care, health, and the costs of achieving them” – Brian Klepper

CCD(Continuity of Care Document) is the result of a collaborative effort between the Health Level Seven and ASTM organizations to “harmonize” the data format between ASTM’s Continuity of Care Record (CCR) and HL7’s Clinical Document Architecture (CDA) specifications. [CORRECTION: See these comments from David C. Kibbe, MD MBA]

HL7(Health Level Seven) is the registered trade mark of the HL7 consortium – an ANSI approved non-profit standards body set up to establish communications protocols for the health industry.

CCD is an attempt to meld  CCR with HL7 standards for data exchange” – jd

“There’s something of a religious war going on here.  BUT many of the more “open” vendors are using both CCR and CCD.  The more “closed” vendors seem to be waiting until CCD “wins” the war” – Matthew Holt

CCD and CCR are often seen as competing standards.  Google Health supports a subset of CCR, while Microsoft HealthVault claims to support a subset of both CCR and CCD” – Mehdi Akiki

IMHO, CCR and CCD are more complimentary than competitive” – Vince Kuraitis

CCD standard is likely to be used by organizations that already use HL7 (large delivery systems), to support existing business models, in non-disruptive applications that achieve cost savings and/or quality improvements by automating EXISTING processes that are INTERNAL TO THE ORGANIZATION (or with existing trading partners), e.g., hospitals sending test result information to doctors and where implementers have already incurred significant fixed costs to adapt HL7 as a broad enterprise standard” – Vince Kuraitis

CCR standard is likely to be used by organizations that have not yet adopted any standard (e.g., early stage companies), to support new business models, in disruptive applications that achieve cost savings and/or quality improvements by creating NEW PROCESSES, often involving parties that are not currently exchanging information, e.g., improving patient chronic care management with the goal of avoiding ER visits and hospitalizations and where the implementers are highly sensitive to incremental costs of IT resources and view the CCR as a “better, faster, cheaper” alternative” – Vince Kuraitis

“Most institutions and vendors that have large investments in HL7 are dealing with the “classic” HL7 versions, the 2.x standards” – Margalit Gur-Arie

“For many applications – especially ambulatory and small companies – the CCR is a complete solution.  Hospitals can also deploy CCR for specific applications.  However, hospitals will not view CCR as a complete data exchange solution for all applications.  Hospitals will need to adopt HL7.  The vast majority of hospitals today are on HL7 2.x.  While HL7 3.x is incompatible with 2.x, my assumption is that hospitals view “eventual” migration to 3.x as necessary, albeit dreaded because of the reasons you cite” – Vince Kuraitis

“Forcing vendors and institutions to adopt those standards (CDA and the RIM), if one can call them standards, will result in increased IT spending all over the board.  I don’t think this is something we need right now.  On the other hand, the CCR is almost “simple stupid” which is a compliment when it applies to a standard and could be implemented at very short notice.  I just think we have to start somewhere and CCR is just the easies and simplest way to start the process and achieve meaningful results” – Margalit Gur-Arie

LOINC , SNOMED , RxNORM – other data exchange standards

“The CCR authors recognize the need for our industry to “ease into” structure … the format does a great job of encouraging coding and normalization without creating an unrealistic bar – this is a tough tightrope to walk” – Sean Nolan

“Both formats (CCR and CCD) are important and help move the ball forward.  We come across situations every day where CCD is a better (or sometimes the only) option for some particular problem, so both HealthVault and Amalga are built to embrace them both.  Frankly this isn’t just a CCR/CCD issue – there are a zillion formats out there holding useful information, and the reality is we’re all just going to have to deal with that for some time to come.  The good news is that we do seem to have a little bit of bedrock in the form of XML and XSLT – these help a ton.  The key thing, I believe, is to stay focused on moving data so that it can be reused and shared – not getting dogmatic about how we move it.  Turns out that when we do that … the right things are happening, a little more quickly with every turn of the crank” – Sean Nolan

“Should there be evidence that any proposed approaches to interoperability will actually succeed in the real world before we declare such approaches as required?  Otherwise, who can determine what approaches to interoperability will prove acceptable to the majority of medical practices?” – Randal Oates, MD

CCR is simple and straightforward” – Margalit Gur-Arie

SureScripts is a certified network able to connect one EHR with another EHR.  Mainly used for connecting doctor’s offices to pharmacies.

“But consider that CVS MinuteClinic is already sending many thousands of CCR xml files from its EHR via SureScripts network, where they are either routed electronically to practices in thexml format (not many yet) or transformed into PDF and sent electronically or faxed.  There is no reason that existing national network operators (e.g. NaviMedix, Zix and Quest, just to name a few that easily come to mind) couldn’t do the same job.  It’s really simply an electronic post office.  There is growing real world experience.  It’s just not coming very often from incumbent health care organizations and vendors” – David C. Kibbe, MD MBA

“Consider this a model (SureScripts, Prescriptions, CVS MinuteClinic) for health network exchange of data like that which is in the CCR standard XML file format supported by Google Health, limited to demographics, insurance info, problem list/diagnoses, medications, allergy and alerts, vital signs, and lab results [I would add consultation reports, hospital discharge and operative reports and test results (ie.  stress test, cardiac catheterization].  Not a lot of data, but meaningful data much of the time.  Kept current and accurate by a person’s healthcare team (nurses, doctors and pharmacists) which includes the patient” – David Kibble, MD MPH

“My argument is that it is much more efficient, and in the long run much easier to implement, a system that pays for the data to be transmitted in CCR format among providers, and between care systems;  and to trust that the market will come up with innovative tools and technologies for helping doctors and patients do this; than it is for government, or anyone else, to pay for complicated “EHRs” that create new silos of data and which force physicians to click dozens or hundreds of times to document a “visit”, while not creating the data set that could be useful in so many ways outside the four walls of the practice to help managed care!  I don’t think this is as complicated as we’re made to think this is, and I know that the tools are available now to get it done.” – David C. Kibbe, MD MPH

“I do agree that the HITECH money would be better spent on facilitating simple data transfer, as opposed to complex data entry” – Margalit Gur-Arie

I have to agree with MD regarding the reality of office and hospital computer systems.  It seems there is a disconnect between the people talking abut all the wonderful things these systems do, and we physicians whose experience with the things in the real world is almost uniformly negative, to neutral at best.  Some of the people with big visions need to visit a hospital or large doctor’s office sometime and see how these things actually work (or don’t)” – Bev M.D.

This summary compiled by Jeffrey E. Epstein, MD