Monday, December 7, 2015

Interoperability, it is more than a set of interfaces.


Last week I had the pleasure of meeting Dan Pettus, VP of Connectivity at CareFusion, we were part of a Panel on The Future of Interoperability at the BIOMEDevice conference in San Jose, CA.  During our  prep for our discussion, Dan provided his view of interoperability, he said that it is more than an technical interface, but the relationship between two systems to communication on multiple layers as well being in sync with each other to the extent that if one side is not working the peer will be affected.   He provided an example,  let’s say that you have an infusion pump that is connected to an EHR and you receive a formulary update in the EHR, the infusion pump(s) must be updated ASAP.  Intelligence must be built into the system to recognize that the update must be sent downstream to the pumps and that the pumps themselves need to be aware of required updates when they comes online.

I had never really thought of interoperability this way, before our conversation.  Endpoint devices do have more than a technical interface,  the easy part of interoperability.  We must consider what other systems are affected when one side of the interface is updated.  We must also take into account how workflows may be affected with peer updates


 When we plan integrations of devices or systems we need to think about the unintended  consequences of interoperability.

Monday, October 19, 2015

“Secure by Design”, IoT in health

Though my subject is Medical Security, this post  extends to devices within our home, auto and our pocket.  If the device is connected we need security to insure privacy.

The most important step to ensuring our privacy and protecting our data starts long before you purchase a device or a new connected devices is added to a hospital or doctors office network.

Security starts in the design of the device and is based on software best practice, many that are not known or enforced in to coder community today. The practice is called  Secure Software Development Life Cycle (S-SDLC) an is taught in the first semester of most Computer Science college curriculum.  This is where I normally lose the Agile designers, but wait, this will work for Agile as well  We just need to consider the sprints as smaller circles/life cycles, more about this later.

There is one large caveat to designing medical software, if it fall under the FDA definition of a medical device it must follow IEC 62304, which is waterfall design, at least for the documentation.  Not all software for medical use need FDA approved, e.g., EHR Electronic Health Records do not fall under FDA jurisdiction, why?  Good question, however we will leave this for another discussion.

One issue software faces today is the lack of Computer Scientists,  there are many great coders doing good work, however the oversight seems to be lax.  Oversight is the responsibility of the vendor that owns the software and the customer who purchases the software, e.g., a hospital purchase a solution to store PHI, something goes wrong and the data is compromised.  It is the hospital responsibility to report and most likely compensate the patient's that have been damaged by the breach.    

S-SDLC

Secure SDLC is based on SDLC, a best practice for designing and delivering robust software.



A series of steps starting at the top of the circle describing the life cycle of the development.
S-SDLC  takes into account security at every step of the cycle, e.g., Requirements phase, add Security requirements.

One of the most important parts of the cycle is testing,  it is the last chance to catch a problem before it gets to the customer.  Because of the emphasis placed on iterations and quick to deliver, many coder today do not agree.

There is a V-Model for SDLC that stresses the testing phase, by including 5 levels of testing.  Many in the Agile community feel that this model is to close to Waterfall design,  I do not wish to debate, however I did want to show the testing phases that must be implemented in-order to protect data.



  • Unit testing
  • Integration testing
  • System testing
  • User acceptance testing


User Acceptance Testing is one of the most important phases because it test in a way that the customer will use the system.  I suggest that organization perform this testing themselves to make sure they are getting the protection and operation that was sold to them.

As IoT solutions become more available in healthcare, we will need to be more diligent in protecting our privacy and the privacy of our patients.  We can no longer except that notion that a product, service or vendor is secure, we must follow through and be sure.

Security isn't something that you can buy as much as it is a way of thinking, designing testing and implementing.   Organization must train their people to think about security first, in everything they do.  We also must implement system that allow employees to report suspected security problem without repercussions, i.e., shooting the messaging .  Security is a team effort, both strategic and tactical.

Friday, June 19, 2015

First Open mHealth Summit, a success for mobile health

I was lucky enough to be invited to the Open mHealth Summit event in San Francisco to witness the unveiling of the latest mobile framework and protocol for healthcare. I have been talking with Dr Ida Sim of UCSF for a few years about there Open mHealth (OMH) project.  We both agreed that there is a need for a protocol/standard to transport data between wireless smart devices without the overhead of the land based HL7 standards such as CDA or CCDA.  Several years before meeting Dr Sim I decided to quit complaining about HL7, so I joined and started try to bring about change in mHealth from within.  When I first read about Graham Grieve's FHIR, a Restful API interface to supplement or replace the CCDA I was thrilled, and implemented a version in a project before HL7 got a hold of it.  HL7 FHIR attempted to solve some of the mobile issues but fell short IMHO by implementing XML and retaining  some of the legacy overhead from the CDA.  FHIR, is good solution for web based solutions that need to communicate directly with and EHR or mobile with 4G, however much of the world including the US doesn’t have 4G and the overhead is still quite high and many solutions do not need to communicate directly with and EHR. 

Dr Sim and her colleagues have a dream to simplify the sharing of health data and there are well on their way to doing it.  If what I saw yesterday is any indication of the future, Open mHealth is the direction to follow.   Open mHealth as it names states is open source, it is not a standard, however most standards do not guarantee interoperability and never will.  The solution is Restfull APIs with “standard” clinical templates to share meaningful data.  OMH already has many supporter that are helping to extend the platform.  Catalyst has a solution that converts OMH into HL7 V2 (circa 1989) the most widely used protocol of healthcare and back again,  now that is interoperability.  There is also a project, Granola to serialize Apple healthKit and that alone is worth the effort to check out OMH.  

OMH doesn’t solve all the Interoperability issues and they are not really trying to, however they are solving the problem of sharing health data and reducing the amount of payload that is transmitted with a mobile smartphone.  Getting the EHR Vendors to except the data or to share their patient data that is locked in their silos is still an issue. 


I am very hopeful and excited about the work OmH has done to date.