Building Unity Farm - Forestry Management

Unity Farm has over 12 acres of forest, which I manage using my Stihl 290 Farm Boss chainsaw and my Scandinavian Forest Axes

I've written previously about managing firewood and logs for mushroom farming

Recently, as we've worked with Tree Specialists on a land management plan that includes an expanded orchard, bees, wildflowers, meadow, and wetland, I've  learned more about tree identification.

As a mushroom expert doing toxicology consultation on the 2500 species of mushrooms in North America, I've become quite comfortable with identification keys.  Recently Barbara Keene of Tree Specialists walked the forests of Unity Farm and taught me how to distinguish white/red oak, red/norway maple, black/sweet birch, cedar, poplar, hickory, ash, dogwood, and elm.

What's the technique?

First, look at the branching pattern of limbs and twigs.  

Maples, Ash, Dogwoods, and Horse Chestnut have opposite branching.    Oaks, birches, poplars, hickory, and elm have alternating branch patterns.

Next, look at the bark

Ash has a diamond-like raised bark pattern. Birches have paper-like peeling bark.  Poplar has a distinctive fissured and ridged bark.  Hickory bark forms ridges in a vertical pattern.   Dogwood is "square plated".     Elm bark is rough and coarse, with intersecting ridges.   Cedar is "string-like".

Finally, look at the buds and nuts.

Maples have distinctive large buds in the spring .   Hickories have a distinctive nut (a favorite of Euell Gibbons)

Thus,  once I've found an opposite branching pattern the presence of a raised diamond or square bark pattern is sufficient to distinguish maples, ash, and dogwoods.

For alternating branch patterns, the presence of paper-like, fissured, vertical ridges, or rough intersecting ridges is enough to distinguish oaks, birches, poplars, hickory, and elm.

The texture and silhouette of cedars (and aroma) are unmistakable.

Buds and nuts help confirm the identification.

Armed with this knowledge, I can harvest fallen branches or dying trees for firewood, mushroom cultivation, or projects that require wood on the farm.   Over time, with help, I'll become a competent forest manager.

The March HIT Standards Committee Meeting

The March HIT Standards Committee focused on streamlining test scripts for certification, an overview of FDA Universal Device Identifier rule making, clinical summary formats for Long Term Care, and the latest updates from ONC.

We began the meeting by reflecting on the recent HIMSS conference, noting that the culture and momentum for EHR and HIE adoption in the US have changed to the point that there is no longer of question achieving our meaningful use attestation goals.

Liz Johnson and Cris Ross provided an overview of the implementation workgroup review of testing scenarios.     Their goal has been to increase the clinical relevance and decrease the burden of testing for certification.   A scenario-based sequence approach enables the reuse of data across multiple tests are part of continuum of functional evaluation.    Part of the work of this group is to ensure the tools provided for testing (9 different tools for Meaningful Use Stage 2) work well and that pre-testing entry of data is allowed, reducing the time of testing procedures substantially.

Next, Terrie Reed presented the FDA's Unique Device Identifiers work.   She discussed the two standards that would be used - GMDN for categories of devices and the use of globally unique identifier for each product (GUDID).   Her analogy to medication vocabulary standards is that GMDN is like RxNorm (a chemical name) and GUDID is like NDC (a specific package size).   She also noted that the regulation will include all medical devices.   The standards committee advised her that the regulation should cover consumer devices used for healthcare as well, so that EHRs and PHRs can be more easily interfaced to consumer devices.

Bill Russell and Larry Garber presented an excellent overview of Long-term Care Coordination standards work, noting that CCDA would benefit from additional templates.

Finally, Judy Murphy and Doug Fridsma presented ONC Updates.

Over the next month, the Standards Committee members will continue their workgroup efforts to select foundational standards for Meaningful Use Stage 3.    I look forward to our next meeting.

The Reality of SaaS

Recently I was asked if SaaS/Cloud computing is appropriate for small practice EHR hosting.

I responded

"SaaS in general is good.

However, most SaaS is neither private nor secure.

Current regulatory and compliance mandates require that you find a cloud hosting firm which will indemnify you against privacy breeches caused by security issues in the SaaS hosting facility.

Also, SaaS is only as good as the internet connections of the client sites.   We've had a great deal of experience with 'last mile' issues"

To add further detail, Bill Gillis, the CIO of the Beth Israel Deaconess Care Organization (BIDCO) responded

"We built, manage & maintain our own private cloud in a Co-location facility.  Our EHR cloud is served to the practice via public internet over SSL. One challenge we struggle with is ISP availability and service level/stability.  In Metro Boston one would expect a robust internet infrastructure.  We've found heterogeneous public internet capabilities and quality of service.  We've found that getting a good ping response is not truly an indicator of meeting application performance requirements.  Many cloud hosted applications are sensitive to latency, packet loss, fragmentation & jitter.

In the first year of our project deployment we struggled because the ISP connectivity did not appear to be the culprit.  A practice would have 10+ megabit connections with ping returns under 25ms.  Yet the practice would experience application freezing, crashes or very poor/slow response time.  From the public ISP's perspective 'the lights were green' and they would take no further action.  After engaging third party network sniffing firm, we discovered the real culprit impacting performance - network latency.  We were able to take the data from that engagement back to the ISP to illustrate the problems with the packets in transit.

Implementing network sniffing engagement was time consuming and costly.  Doing this for the 100+ practice locations we were supporting is not sustainable.  Luckily we found a company in Boston called Apparent Networks (now called Appneta).  Appneta makes a small, low cost black box application that provides deep and detailed network data back to a secure cloud.  We place a device in a practice that communicates back to a device we keep in our hosted/central site.  The devices continually communicate with each other and log all of the various degrees of network performance up to the cloud.  The best part is we preconfigure the devices and mail them to the practices reporting issues.

 All the practice staff need to do is provide power and plug it into an open Ethernet port.  This saves us from deploying a technician on-site.  Since we first deployed these devices we've been able to get to the root cause of performance issues and resolve them rapidly.  We've been able to identify everything from an ISP charging for a certain level of bandwidth while only providing 1/2 that speed to staff streaming media during high volume hours saturating the local router.  The performance data is stored in the cloud indefinitely.  This give us a longitudinal view of the network/internet connectivity for a specific practice.  Recently we were able to avoid a potential issue by noticing that a practice's connection stability was slowly degrading over the past year.  We were able to work with the ISP to discover they had an issue with a local Central Office/substation.  The reality is most ISP's are not that willing to work with us until we show them the data.  Once we have the smoking gun, they tend to dig deeper and work with us to resolve the problems.  For all the high-tech equipment we've leveraged for our private cloud, this device was the real swiss army knife of the project."

I've described Cloud Computing as "your mess run by someone else".   It can be done successfully, but SaaS is only as good as the privacy protections you purchase or build yourself.   Performance is only as good as your network connection.

I hope this is helpful.

Building Unity Farm - Managing the Farm in Our Absence

Paul Harvey wonderfully captured the responsibilities of being a farmer.  Just like being a CIO, being a farmer is not a job but a lifestyle.

When I called my wife and daughter in the hours after my father's death last week, we had to figure out how to manage Unity Farm during a situation that required the absence of the entire family.

We created a workplan and contacted a nearby farm to ask for their help.

Here's what we had to document

Alpaca/Llama care
  Hay management in two indoor and two outdoor feeders
  Twice daily grain feedings
  Heated water bucket filling
  Snow clearing in the alpaca paddocks
  Manure management in the barn, paddocks, and composting area

Chickens/Guinea fowl
  Feeder filling (with multi-flock crumbles)
  Providing greens (romaine lettuce)
  Heated waterer filling
  Coop cleaning
  Opening and closing the coop during daylight hours
  Counting all the birds to ensure they return from their free range adventures
  Turning on the inside lights during the day and off at night (guineas will not roost in a dark coop)

Dogs
  Feeding the dogs in the evening
  Heated water bucket filling
  Providing them snacks and toys

Rabbits
  Lettuce feeding
  Hutch cleaning

General
  Ensuring fences are not damaged by falling tree limbs or snow drifts
  Managing the electric fences
  Ensuring protective lighting is working to keep predators away
  Keep barn doors closed
  Keep property safe

We never expected to all be away from the farm at the same time, so creating detailed instructions required significant short term work.

A farm hand from our adjacent farm did a wonderful job and I returned on Sunday night to find Unity Farm in perfect shape, other than one barn light that was knocked down by a falling tree limb.    Kathy stayed with my mother an extra week and returns to the farm on Saturday.     Just as IT professionals plan for redundancy and disaster recovery,  Kathy and I have learned the importance of contingency planning for the farm.    We have been an inseparable team for 33 years.   Keeping all our professional and personal activities in balance is easy when we're together, but nearly impossible when we're apart.

A Unified Software Development Lifecycle

Recently, in response to an audit, I was asked to document our Software Development Lifecycle across all our platforms - clinical, financial, and web.    Here's what I wrote.  I hope you find it useful.

1.  Project Definition

Multi-stakeholder governance bodies of business owners and IS professionals meet on a regular basis to define the scope and requirements of new projects.    The priorities of these new projects are based on business owner strategic alignment, regulatory/compliance requirements, quality/safety imperative, impact factor (employees, clinicians, patients),  and return on investment.    Governance Committees with oversight over the software development life cycle include:

Clinical - webOMR User's group sets ambulatory development priorities.    Inpatient Clinical Applications Steering Committee sets inpatient development priorities.

Financial/Billing - IS project manager and IS fiscal manager work with Patient Financial Services stakeholders to mutually agree on the work tasks of all programmers.

Financial/Supply Chain Manaagement/Research/ERP -  Human Resources/Payroll, General Accounting, Research Finance and Supply Chain Management Steering Committees set Peoplesoft and related application priorities

Web Applications  - the Portal steering committee sets web development priorities

Once a project is approved by a governance committee, it is assigned a tracking number and assigned to programmer

In addition to project definition, these committees also oversee the portfolio of work their specific domain.    This includes monitoring progress and identifying/eliminating barriers to success.

2. User Requirements Definition, Analysis and Design

The development process for approved projects begins with user requirements definition.   This is a collaborative effort involving developers, analysts and business owners.  It is an iterative process in which a prototype is developed based on an initial set of user requirements and then modified in response to user feedback.   Multiple cycles of revising requirements and prototypes typically occur.   We employ an agile development methodology with source code control systems/versioning for every development platform.

3.   System requirements definition

Application projects may have infrastructure implications.   An infrastructure project manager is engaged if additional server capacity, novel desktop configuration, or new client hardware (mobile, specialized printers, bar code scanners) is required as part of the application

4.  Testing

BIDMC maintains dedicated development and testing environments that are separate from live/production.     Developers first unit test their changes.   Application analysts independently test changes.    End users perform acceptance testing.

Test scripts are used to perform integrated testing before go live.

No code is moved into production before end user signoff approval.

5.  Go live and continuous improvement

Go live is planned in collaboration with business owners which includes communication and post go live support planning.     Changes to infrastructure and communication plans for major go lives are presented to the IS Change Control Board to ensure awareness and coordinate timelines among all IS projects.

The push of code from a testing environment to a production environment is done via a source control system, is logged for auditing purposes, and may be rolled back quickly.   For clinical applications, this push is done by the most experienced developer, as experience has shown that this person is most able to ensure a successful deployment and rapidly identify any defects, minimizing risk.   For financial/billing  applications, this push is done by the non-IS Production Control group, since mainframe workflows are more batch oriented and more amenable to segregation of duties in go live processes.   The organization accepts this difference between the clinical and financial/billing go live process as necessary to reduce overall risk.

Once the go live push is completed, success of the process is validated by the most experienced developer, the analysts, and/or the business owner as is appropriate for the application.

Based on feedback during the go live validation process, a rollback may be done if there are unexpected consequences.  This is a very rare event, but it supported by the source code control systems which drive the go live process.

Once application  changes are live, user feedback is provided at the governance committee level and products are continuously improved to meet users needs, always following the above Software Development Lifecycle.