HLN ConsultingInnovators in Public Health Informatics

Category Archives

38 Articles

HLN releases Version 1.13.1 of its Award Winning Open Source Immunization Forecaster

Share

HLN releases Version 1.13.1 of its Award Winning Open Source Immunization Forecaster

A new release (v 1.13.1) of the Immunization Calculation Engine (ICE) is now available (download ICE version 1.13.1). ICE is a state-of-the-art open-source software system that pro ...

A new release (v 1.13.1) of the Immunization Calculation Engine (ICE) is now available (download ICE version 1.13.1). ICE is a state-of-the-art open-source software system that provides clinical decision support (CDS) for immunizations for use in Immunization Information Systems (IIS), Electronic Health Record (EHR) and Personal Health Record (PHR) Systems.

The release includes support Earliest Date and Overdue Date for additional vaccines: Pneumococcal and Hib. If enabled, ICE will output two additional forecast dates along with the Recommendation Date: the Earliest Date and Overdue Date. The Earliest Date is the soonest date that the vaccine can be given and still be considered valid. The Overdue Date is the date after which an immunization administered would be considered late. With this release, ICE returns the earliest and overdue dates for nine vaccine groups, and the remaining three vaccine groups will be completely supported in a future release of ICE this summer.

In addition, this release includes an adjustment to the Pneumococcal catch-up schedule (see Exception 1B in the Pneumococcal Vaccine Group documentation for details). All changes are documented in the release notes. There were no changes to the ICE Implementation Guide (v2r20) which describes how implementers should update their installation and software to properly read the Earliest, Recommended, and Overdue dates.

Feel free to e-mail us at ice@hln.com if you have any questions.

HLN Submits Comments to CMS on IPPS NPRM

Share

HLN Submits Comments to CMS on IPPS NPRM

On June 14, 2018 HLN submitted the following comments on the Centers for Medicare and Medicaid Services (CMS) 2019 Inpatient Prospective Payment System Notice of Proposed Rulemakin ...

On June 14, 2018 HLN submitted the following comments on the Centers for Medicare and Medicaid Services (CMS) 2019 Inpatient Prospective Payment System Notice of Proposed Rulemaking (NPRM) to Quality Payment Program based on our earlier comments:


HLN Consulting, LLC is pleased to submit the following comments on the recently-released CMS IPPS NPRM, CMS–1694–P. HLN is a leading public health informatics consulting company. With that in mind, we read documents like the NPRM through a public health lens, and confine our comments to that important context.

Thoughts on the CMS IPPS NPRM: A Public Health Perspective

Share

Thoughts on the CMS IPPS NPRM: A Public Health Perspective

I have seen several pretty good summaries of the recently release Centers for Medicare and Medicaid Services (CMS) 2019 Inpatient Prospective Payment System Notice of Proposed Rule ...

I have seen several pretty good summaries of the recently release Centers for Medicare and Medicaid Services (CMS) 2019 Inpatient Prospective Payment System Notice of Proposed Rulemaking (NPRM) to Quality Payment Program (one from AMIA, one from CDC). Here are just a few additional tidbits I picked out of the NPRM.

Of course, this document is written like stereo instructions so I welcome any corrections or comments to my interpretation of what’s in the rule. I put page numbers (from final FBO version referenced above which has just been released) where relevant in parenthesis.

Epic and Cerner Connect to HLN’s ICE at FHIR Connectathon

Share

Epic and Cerner Connect to HLN’s ICE at FHIR Connectathon

At the 18th FHIR Connectathon in Cologne, Germany on May 12-13, 2018, HLN successfully integrated its open source Immunization Calculation Engine (ICE) service with test instances ...

At the 18th FHIR Connectathon in Cologne, Germany on May 12-13, 2018, HLN successfully integrated its open source Immunization Calculation Engine (ICE) service with test instances of two Electronic Health Record (EHR) products, Epic and Cerner, using the CDS Hooks standard.

CDS Hooks is an emerging specification for invoking third-party Clinical Decision Support (CDS) web services from various points within an EHR workflow, such as whenever a patient is viewed. Registering a CDS service in an EHR is as easy as supplying a service discovery URL.
When invoked, the ICE CDS Hooks service accepts patient demographics and immunization history supplied by the EHR in FHIR format; calls the ICE decision support service; and sends back immunization forecasting alerts to the EHR for display.

The Connectathon was held prior to the May HL7 Working Group Meeting in Cologne. Version 1.0 of the CDS Hooks standard (cds-hooks.org) is being voted on during the May 2018 HL7 ballot cycle.

More information on ICE is available at cdsframework.org.

HITAC USCDI Task Force Delivers its Recommendations

Share

HITAC USCDI Task Force Delivers its Recommendations

On April 18, 2018 the HHS Health Information Technology Advisory Committee (HITAC) US Core Data for Interoperability Task Force delivered its recommendations on the draft US Core D ...

On April 18, 2018 the HHS Health Information Technology Advisory Committee (HITAC) US Core Data for Interoperability Task Force delivered its recommendations on the draft US Core Data for Interoperability (USCDI) and Proposed Expansion Process which had been published for public comment back in January 2018. HITAC promptly accepted the Task Force’s recommendations.

The Task Force focused almost exclusively on the process for identifying the USCDI rather than the proposed USCDI data itself. I especially appreciated their introduction of some key concepts related to how USCDI should be organized and understood. It has always bothered me that the current Common Clinical Data Set (CCDS) upon which the current draft USCDI is based contains a variety of types of data at different levels of analysis: for instance, a single discreet data element (like date of birth or sex) sits alongside more complex data constructs (like address, which contains many discreet data elements within it) which sit alongside even more complex data types (like immunizations or procedures). The Task Force introduces a notion of hierarchy to make this more sensible: data classes (high level topic like “demographics”), data objects (a single item within a class, like “address” within the class “demographics”), and data object attributes (a specific data element within a data object, like “zip code” within “address”).

From a process standpoint, the Task Force recommended an expanded set of steps which has an emphasis on more stakeholder participation and less ONC pronouncement. This includes a recommendation for patient input as well. These are welcomed additions and I certainly hope they will be operationalized by ONC.