Showing posts with label Connectathon. Show all posts
Showing posts with label Connectathon. Show all posts

Thursday, January 18, 2018

CQL for Me, or what not to do at an IHE Connectathon

Testing22222
If you think you are going to implement a brand new feature during Connectathon week, then you probably are about as brain dead as our poster child for accidents waiting to happen on my right.  Having said that, my job for this week is to at least get started on implementing a clinical quality language execution engine into my FHIR Server.

So much for brains, right?  One of the biggest challenges I've had is that while there's plenty of open source implementations out there, there's not a whole lot of documentation on how to use them.  And while as a language, CQL is certainly easy enough to read, there's some very basic assumptions about a programming language that are left completely unstated in the standard.

"What does hello world look like in CQL?" is one of those questions that I hadn't found (nor could Google) anyone addressing.

That's a really good question.  The answer isn't to be found in the CQL Specification, but I did eventually figure it out.  It looks like this:

define result: 'Hello world!'

Pretty simple.  The execution of a CQL program basically produces a list of results, where each result has a name and a value.  This makes it really ideal to use a JSON representation for output, by the way.  There's also a type (associated with the value), and a location associated with the definition that you can get out of the engine I'm using (which makes it really handy for debugging).

This was my DUH moment last night.  Now it doesn't have to be yours.  I think I'm about to join that open source community as a doc writer (at least to start off).

   Keith

Tuesday, January 16, 2018

Converting STU2 to STU3 in HAPI on FHIR

AC Converter Adapter USA-EU
So, you've built your HAPI FHIR Server, and if you started when I did, you may have even started with STU2.  But these days IHE profiles are in STU3.  What's a guy to do?  Well, if that guy is an engineer, the first thing you WON'T DO is rewrite your server from scratch.  For PIXm, PDQm, QEDm and likely even MHD (although I haven't checked that profile out yet), the simple answer is to front end your STU2 services with an STU3 facade.

The pattern for such a facade is fairly simple:

public class MySTU3ResourceProvider  {
  private final MySTU2ResourceProvider stu2Provider;
  private VersionConvertor_10_30 converter = 
     new VersionConvertor_10_30(new NullVersionConverterAdvisor30());

  public MySTU3ResourceProvider(MySTU2ResourceProvider stu2Provider) {
     this.stu2Provider = stu2Provider;
  }

  @Search() Bundle doQuery(...) {
     try {
       // call the previous method and get the bundle response
       return coverter.convertResource(stu2Provider.doQuery(...));
     } catch (BaseServerResponseException ex) {
       // We got a "normal" exception from the processing.
       Object o = 
           converter.convertOperationOutcome(
               (OperationOutcome) ex.getOperationOutcome());
             ex.setOperationOutcome((IBaseOperationOutcome) o);
       throw ex;
     } catch (FHIRException fex) {
       throw new InternalErrorException(fex);
     }
   }
   @Read Resource doRead() {
     try {
       // call the previous method and get the bundle response
       return coverter.convertResource(stu2Provider.doRead(...));
     } catch (BaseServerResponseException ex) {
       Object o = 
           converter.convertOperationOutcome(
               (OperationOutcome) ex.getOperationOutcome());
             ex.setOperationOutcome((IBaseOperationOutcome) o);
       throw ex;
     } catch (FHIRException fex) {
       throw new InternalErrorException(fex);
     }
   }
}

One of the things I learned this week was that I needed to add the conversion trick to handle any cases where the original method throws something derived from BaseServerResponseException.

This is great.  Until you discover that for some reason, convertMedicationOrder hasn't been implemented, and you need to turn your previous MedicationOrder into a MedicationRequest.

So, buckle down and write convertMedicationRequest(), or use the code I wrote below.  Here's how I started: It took me about 3 minutes to find that the code had been commented out.  It took me another 15 or so to code it up, and a few more to test and tweak it.  All told, about 30 minutes. To skip to the chase, here's the code (it's not pretty, but it seems to compile and run):

VersionConvertor_10_30 converter = new VersionConvertor_10_30(new NullVersionConverterAdvisor30()) {
    
      public org.hl7.fhir.dstu3.model.Resource convertResource(org.hl7.fhir.instance.model.Resource src) throws FHIRException {
      if (src instanceof org.hl7.fhir.instance.model.MedicationOrder) {
      return convertMedicationOrder((org.hl7.fhir.instance.model.MedicationOrder)src);
      }
      return super.convertResource(src);
      }
      
      public org.hl7.fhir.dstu3.model.MedicationRequest convertMedicationOrder(org.hl7.fhir.instance.model.MedicationOrder src) throws FHIRException {
      if (src == null || src.isEmpty())
        return null;
      org.hl7.fhir.dstu3.model.MedicationRequest tgt = new org.hl7.fhir.dstu3.model.MedicationRequest();
      copyDomainResource(src, tgt);
      for (org.hl7.fhir.instance.model.Identifier t : src.getIdentifier())
        tgt.addIdentifier(convertIdentifier(t));
      tgt.setStatus(MedicationRequestStatus.fromCode(src.getStatus().toCode()));
      tgt.setMedication(convertType(src.getMedication()));
      tgt.setSubject(convertReference(src.getPatient()));
      tgt.setContext(convertReference(src.getEncounter()));
      if (src.hasDateWritten())
        tgt.setAuthoredOn(src.getDateWritten());
      tgt.getRequester().setAgent(convertReference(src.getPrescriber()));
      if (src.hasReasonCodeableConcept())
        tgt.addReasonCode(convertCodeableConcept(src.getReasonCodeableConcept()));
      if (src.hasReasonReference())
        tgt.addReasonReference(convertReference(src.getReasonReference()));
      if (src.hasNote())
        tgt.addNote().setText(src.getNote());
      for (org.hl7.fhir.instance.model.MedicationOrder.MedicationOrderDosageInstructionComponent t : src.getDosageInstruction())
        tgt.addDosageInstruction(convertMedicationOrderDosageInstructionComponent(t));
      if (src.hasDispenseRequest()) {
      MedicationRequestDispenseRequestComponent dr = tgt.getDispenseRequest();
      MedicationOrderDispenseRequestComponent sr = src.getDispenseRequest();
      if (sr.hasValidityPeriod()) 
      dr.setValidityPeriod(convertPeriod(sr.getValidityPeriod()));
      if (sr.hasNumberOfRepeatsAllowed())
      dr.setNumberOfRepeatsAllowed(sr.getNumberOfRepeatsAllowed());
      if (sr.hasQuantity()) 
      dr.setQuantity(convertSimpleQuantity(sr.getQuantity()));
      if (sr.hasExpectedSupplyDuration()) 
      dr.setExpectedSupplyDuration(convertDuration(sr.getExpectedSupplyDuration()));
      }
      if (src.hasSubstitution()) 
      tgt.getSubstitution().setReason(convertCodeableConcept(src.getSubstitution().getReason()));
      tgt.setPriorPrescription(convertReference(src.getPriorPrescription()));
      return tgt;
    }


    };

This week is all about getting things close enough.  Afterwards I get to bring the code back to turn it into production.  But I'm guessing that I'm not the only one wanting to convert STU2 MedicationOrder resources into STU3 MedicationRequest resources.  So, here you go.

   Keith

P.S.  As to why this is commented out, my suspicion is that the code generator that is producing the converter from the FHIR Specification hasn't quite been tuned to deal with Resource name changes yet.

P.P.S. Source code in this post is CC-By 3.0

Thursday, January 28, 2016

A belated post on Day 1 at the IHE Connectathon

I'm a bit behind in posting on my Connectathon experiences this week.  After you read my day one post you might understand. I started off this year as I always do, hunting down the guy who was going to tell me what our priorities are this week so I could help him to make a plan for succeeding (what I usually expect him to have prepared in advance).  Some years are better than others, and there's a plan to work from.

When I got to his seat, I had a stunning realization. Oh shit, that's where I'm sitting.

   Keith

Wednesday, August 26, 2015

IHE NA Connectathon 2016 Kickoff Webinar--September 14

 

What is an IHE Connectathon?

Check out the IHE NA Connectathon testing floor.

 

 

IHE NA Connectathon 2016 registration
opens soon!

Can your crew brave five days of intense interoperability testing with 100+ vendors and 550+ engineers at the IHE North American Connectathon? Discover if you have what it takes to participate — register now for the Kickoff Webinar on Monday, September 14.

Monday, September 14, 2015 |  10:30 am — 11:30 am CT.

Showcase your achievements at the HIMSS Interoperability Showcase™ at HIMSS16
It's go time. Take your game to the next level and demonstrate live interoperability at the HIMSS Interoperability Showcase.
Reserve your spot today. Send in your contract by September 1 for early bird renewal rates.

 


Friday, August 23, 2013

IHE USA's Registration Kick-off Webinar | August 27, 2013

In my inbox this afternoon ...

Prepare Your Team for Health IT's Largest Interoperability Testing Event:
The IHE North American Connectathon 2014



Integrating the Healthcare Enterprise's (IHE) North American Connectathon provides an unparalleled opportunity for interoperability testing and problem resolution. Take an active role to advance your products and test at the IHE North American (NA) Connectathon, January 27-31, 2014. To learn more, register for the Registration Kick-Off webinar.
Discover the Benefits of Connectathon Testing
Reduce Development Costs and Time to Market:
  • Debug systems within minutes leveraging a broad cross-section of industry partners on-site
  • Leverage 15 years of test tools developed in partnership with IHE and NIST
Build Quality into your Products:
  • Certify your products for interoperability using an ISO accredited lab and ONC-authorized certification body
  • Implement best practices using IHE Integration Profiles to enable key interoperability capabilities
  • IHE's structured, supervised and independent testing environment ensures the highest quality products



Meet Industry's Standards for Interoperability:
  • New! Test emerging standards offered by industry partners including Continua, Health Story Project and ONC S+I Framework Health eDecisions
  • Prepare for MU Stage 2 certification requirements focused on Consolidated CDA integration
  • Prepare for integration with key North American initiatives that leverage IHE Profiles including:
    • ONC S+I Frameworks
    • Meaningful Use Stage 2 Certification
    • HealtheWay
    • New York eHealth Collaborative
    • Care Connectivity Consortium
IHE Connectathons are held annually across the globe. The NA Connectathon is sponsored by IHE USA in collaboration with IHE Canada. To learn more visit our website or contact secretary@iheusa.org.
Join the conversation. Follow us on Twitter at @IHEUSA or visit our YouTube Channel.

You have received this email because you are opted-in to receive
information about distance education. 

Want to control your email from HIMSS?
Update your profile or unsubscribe from emails.
If you have any questions or problems please contact us at techsupport@himss.org.
33 West Monroe Street, Suite 1700, Chicago, IL 60603-5616


Tuesday, November 20, 2012

Sneak Peak at the IHE North American Connectathon Conference 2013


January 30, 2013 at Hyatt Regency Chicago, IL. Register today!

IHE USA is proud to announce the IHE Connectathon Conference 2013, Wed. January 30, 2013 at the Hyatt Regency in Chicago, IL. The conference is the cornerstone of the North American Connectathon. Join us as we discuss the many ways that technology and IHE is enabling the achievement and sustainability of the meaningful use of healthcare information technology. Read more about the conference and register today.  


Achieving and Sustaining Meaningful Use: The Role of Standards and Integration

The goals of delivering meaningful use of healthcare IT focuses on a wide body of stakeholders and quality measurements making this achievement epic in the industry. However, none of these goals would be possible without the efficient use of interoperable systems that enable the quality care. IHE is the grandfather of interoperability and the foundation for new technology that enables the seamless transfer of data across the healthcare continuum.

Learn more at the IHE Connectathon Conference and educational sessions as we highlight the unique goals required to achieve meaningful and IHE’s role in their development including:
  • Connecting clinicians, patients, and their families with the tools and resources needed to enable care in a seamless, meaningful, transparent way. 
  • Achieving quality and efficiency of data as related to the delivery of care. 
  • Empowering patients at home and beyond. 
  • mHealth ecosystem that extends access and connectivity to individuals delivering care.

Register today for a full day of exciting and dynamic educational sessions focused on the role of achieving meaningful use through interoperability and IHE. 

Monday, January 9, 2012

Good Luck at Connectathon

I'm not going to be at Connectathon this year for the first time in nine years.  Something came up last week, and I need to be here working on other interoperability problems.  I won't be onsite helping people figure out how to record allergies to peanut butter, looking for people in orange shirts (or whatever the color is this year for monitors), or trying to figure out how why my X-ray image isn't displaying in my XDS-I implementation (it was an AE-Title mapping to WADO Server URL problem that time).

I'm going to miss being there.  There are a lot of people there that I only see at IHE events.  I won't get to see the Connectathon Conference (but if you can, you should go!)

I won't be able to take pictures of normally competing vendors working all night long to make sure their systems interoperate.

While I'm certain to get a call or two from the Connectathon floor, I'm actually quite comfortable here.  It's a shame though, because for the first time in 9 years, the weather in Chicago appears as if it's going to be rather mild.

Tuesday, January 3, 2012

A Duct Tape Week

It's my first official day back on the job in the new year.  Some days, I feel like the glue that keeps things together, and other days, like duct tape keeping things from falling apart.

Glue days are when I manage to connect up this person with that fact or other person, or that product with this other team, or that project with this other detail.  Duct tape days are when I manage to keep things from falling apart by making sure this person talks to that one, or reassure that person that because of this detail, they need not worry, and so on.

The difference between glue and duct tape is in how fast it works, and how permanent the solution is.  Glue takes a bit of time to set, but usually creates a pretty permanent solution that doesn't need to be addressed later.  Duct tape is very quick, and can keep things from falling apart, but it is by no means a permanent solution.  Glue is mostly used for building, and is sometimes used for (permanent) repairs.  Duct tape is mostly used for repairing things, but can occasionally be used to hold things together while glue sets.

Today, getting back, catching up, and getting ready for the next two weeks, I'm barely managing to tread water.  Thus, it is a duct tape day.  I'm ripping and sticking as fast as I can to hold things together until I get real time to figure out a more permanent solution.

A good week is when I spend less than 10% of my time dealing with duct tape.  A really bad week could be covered in it, but I haven't had a really bad week in a long time.  Mostly that has to do with preparation.  If you are prepared, you might need to break out the duct tape from time to time, but most of the time, you'll be using glue.  There are times though, when duct tape is perfectly acceptable, and duct tape days are the norm.

Connectathon is next week.  A great deal of duct tape will be used there. This is not a bad thing.  The whole point of Connectathon is not to discover what works, but rather, to figure out what doesn't and get it working.  Teams that succeed at connectathon wind up with improved products, and even those that fail often learn a great deal.  The point is, once you've learned what is broken, you can go back, and figure out how to really fix it (in the weeks after connectathon).

Here's wishing you all a great duct tape week.



Wednesday, February 16, 2011

Thank you for attending the IHE N.A. Connectathon Conference 2011- Post-Conference Highlights

This was in my inbox a few weeks back, and I thought I'd share it with you because some of the links are useful, but then I never posted it. Well, here it is, if a few weeks late...


Thank you for attending the IHE N.A. Connectathon Conference 2011.

On behalf of IHE USA, thank you for participation at the IHE N.A. Connectathon Conference on Tuesday, January 18, 2011. The conference attracted over 150 attendees to Chicago for an important convergence of thought leadership in the health IT industry. We hope you enjoyed the educational programming and networking.

As each of you witnessed during the guided tour of the IHE N.A. Connectathon testing area, the Conference is just one important element during the rigorous five-day testing marathon. As a result, we would like to share both the Conference highlights and final Connectathon statistics. Please visit the IHE USA website or use the direct links provided below to view the highlights from the week.

IHE N.A. Connectathon Conference 2011 highlights:
IHE N.A. Connectathon 2011 testing event:


If you have any additional questions or would like to become involved in IHE, the IHE Global Connectathons or HIMSS Interoperability Showcases, please contact secretary@ihe.net. We will be glad to speak with you individually.

Thank you on behalf the Board and staff at IHE USA.





Friday, January 21, 2011

This is Connectathon

By the time most of you read this, the connecthon is largely over.  If you haven't finished your testing tonight, you better have only one or two more to get through tomorrow.  Otherwise, you are might as well be outta here -- which could be the only sliver lining in this cloud given the travel delays anticipated today.



Think of what follows below as "Director's Commentary". 

0:00 - 0:07 As you come in to this video, you'll see someone on the far right who is looking for where the person he expects to be sitting right here is.


0:04 - 0:12 Moving in from the right are engineers from two different products working out what they need to do to make it work.

0:12 - 0:18 In the middle background you can see this one fellow in quite a hurry to see what's going on with his partner over there.

0:16 - 0:23 And then we have this guy who is NOT running to the bathroom (which are behind us in this scene).  He must have even more to get done this week.
0:25 - 0:29 Striped Shirt: "If you do this it will work." Blue Hooded Sweatshirt: "Ok! I got it now."

0:28 - 0:31 He's reading the spec.  Can I keep him?

0:33 - 0:34 Engineer to carefully listening monitor ... So what we do to protect the data is...

0:36 - 0:40 That guy taking notes doens't usually work with the other two.


0:41 - 0:43 Team Programming

0:48 - 0:50 Hmm, what is going on here?

0:51 - 0:52 Lotsa Interop happens inside these boxes. They use LBL (little blinking lights) technology.

0:54 - 1:00 On the phone back to the office. "What I need you to do is ..."

For some of this, it is good bye for another year, for others, see you in committee in Toronto in two weeks, and for others, til we meet in Pisa in a few months.

For all of us, it is Connectathon, and to all who participated, "Good Luck! And see you again next time."

P.S.  Thanks to all my birthday well-wishers and to whoever had them send a cake to my room.

Wednesday, January 19, 2011

Two Rules for Connectathon

“   Two rules of software development
  1. Just get it to work
  2. If it ain't broke, don't fix it.

I've written about these rules before.  For connectathon they apply in spades.

Violate rule number 2 at your own risk.  If you decide that you need to do a clean install just before you get here, make sure you have it all.  Sometimes doing unnecessary work to fix things does more damage than living with what you had already tested.

On rule number 1, if you are having a problem, work first on getting it fixed to the point that it passes.  Make the fix elegant and maintainable when you have more time (and keep good notes).

There's another thing about rule #1.  If you cannot get it to work with partner A, don't spend hours trying to work it out.  Find another partner to test with to see if you can just get it to work.  Don't let a blocking problem keep you from completing other activity.

Finally, one last note:  If you cannot get it to work with A + B + C all at once, simplify.  Try to make it work with just one of them.  Then add the other, then put it all together.  Don't try ATNA TLS + ATNA Logging + PIX Query + XDS Provide and Register as your very first test.

Tracking your progress at Connectathon

After over eight (!) years participating at the IHE Connectathon, I've developed a number of techniques to determine how on track I or teams I'm supporting are.  These are really simple metrics.

Day one:
Did you come with your stuff and are you on the network by 9:00?  Good
Are you still having network problems at 10:00? Bad
At the end of the day, have you done ALL your no-peer testing?  Good
Are they all verified?  Excellent.
Have you made progress on peer-to-peer testing?  Good
Have you made 0 progress?  Really bad.
NOTE:  In past years, connectathon monitors have been told on Wednesday to focus priorities on peer-to-peer testing, because if you haven't finished your no-peer tests by then, likely you will fail.

Day two:
At the end of the day, do you feel like you will finish peer-to-peer tomorrow?  Good
Have you nearly finished or finished peer-to-peer testing on any profile?  Excellent.
Do you still have more than half of your peer-to-peer testing to finish?  Bad
Still not connected?  If you cannot connect tomorrow, better check for an early flight out. 

Day Three: 
At the end of the day, are you done peer-to-peer testing?  Good. 
Are they all verified?  Excellent. 
Are you nearly done?  Don't panic YET, but get it done first thing, or stay late if possible.
Still not connected?  Go home.

Day Four:
Did you make progress on group tests?  Good.
Did you finish group tests?  Excellent.
Still not connected?  Why are you here?
All done?  Excellent.  Now is the time to go for stretch goals or help colleagues.

Day Five:
Ready to be told you can leave?  Excellent.
Nearly done?  OK, but scramble.

If, along the way you discover that you WON'T be able to meet some of the criteria for a profile, and you don't have another reason to keep testing it, DROP it, or at least don't waste any more time on it.  Dropping a profile is a favor to others who may otherwise try to test with you.

This morning's connectathon lesson is brought to you by the Llama.

The Connectathon Conference

It's a bit of a different experience being an attendee at the Connectathon Conference than it is being on the Connectathon floor.  For one, since I was speaking, I wore a suit.  Most of the people attending the conference don't know me, and I figure it makes it easier for them to accept me as an expert if I don't get too much in their face about it.  For another, its an opportunity to hear about how people are using IHE in the real world.

I missed Lisa Spellman's introduction, but I caught Elliote Sloane's (IHE International Board Chair) presentation.  Elliote talks about the history of IHE (going back to 1998), its growth, its newest (and oldest) international member (IHE USA - where he is also on the board).  He also talks about the growth of connecthon participation this year, where we have over 100 companies testing more than 55 IHE profiles.  Last year is was more than 80 companies and 55 profiles.  That's better than 20% growth.  At a dinner later in the evening, I was talking about IHE's growth since I first showed up on the scene.  It's pretty darn impressive.  Since 2001, the North American Connectathon has grown in participants at an average rate of better than 12% a year, and when I look at the total figures (Europe, Asia and other Connectathons), it is growing even faster, better than 15% a year.  I wish I was getting that kind of return on my investments.

Here's a chart of the data I dug up from the Connectathon results on connectathon participation.

Dr. Doug Fridsma, Director of Standards and Interoperability at ONC joined IHE at the Connectathon Conference as the keynote speaker.  Doug ran the audience through his current vision of the Standards and Interoperability Framework.  He highlighted some key points.  One was that specifications should be crisp, and include everything you need with nothing more, and they need to be extensible.  He also highlighted the three recently announced initiatives, one of which includes participation from 3 IHE co-chairs and one board member along with several other IHE members, that being the HL7/IHE/Health Story Consolidation project.  I also introduced several members of the IHE Lab workgroup to Doug and I believe we convinced them to participate in the Laboratory Interface Improvement project.

The Consolidation project is intended to address the biggest issue HITSP was never funded or contracted to address.  That is the creation of a one-stop specification for the implementation of CDA documents.  It goes just a bit further in that not only is there a specification, but also a UML model.  That's critical for future IHE/HL7 and ONC collaboration efforts.  If we all publish the necessary data in the UML model in a standard format like XMI (I just picked that one out of a hat), implementers of CDA would be able to:

1.  Use off-the-shelf tools to create software for reading and writing CDA documents.
2.  Create implementation guides based on the CDA standard.
3.  Share implementation guide data for use by others.

It restores what we tried to accomplish in the first years of IHE PCC by creating the content on the wiki, but in a much better way.  The MDHT CDA Tools project produces DITA output.  That can be transferred to proprietary formats like Microsoft Word, or standard formats like PDF, DocBook or even, heaven forbid, well-linked XHTML.  I'm eager to see what we can do with the tool, and hopeful that IHE PCC can begin to use it to develop profiles.  IHE Radiology is looking at MDHT as well, because they have some CDA templates to create this year also.

Mike Nusbaum gave his update on IHE Canada and how it now fits into the Canadian Standards Collaborative (until recently, IHE Canada participated indirectly, but wasn't part of the collaborative).

Lee Jones (formerly of the former ONC and HITSP) gave an update on the current health IT environment.  The most memorable phrase from his slides were "Meaningful Frenzy", which pretty much describes my life for the last year and the next two.  He also pointed out operational challenges seem to be more daunting than than the technology ones that the PCAST tries to address.  He notes that payers haven't until recently been engaged in mainstream interoperability, but that recent acquisitions of HIT by Payers may be signalling a change. 

After lunch, we heard from Dr. Keith Dreyer who is doing some truly cool things with image sharing in EHR systems at MGH.  IHE has recently developed the Image Enabled Office which looks very similar to the image integration capabilities in Mass General's LMR.  Dr. Dreyer also reports some amazing reductions in use of high cost imaging procedures using CPOE and Clinical Decision Support

Next I gave a workshop on creating IHE profiles, and again, we came up with a winner and three other proposals that will be forwarded to other IHE domains.  The winning submission which I will champion at the next opportunity in PCC is enabling information exchange from pre-surgical information systems to the hospital HIS system.  The American Dental Association is sponsoring a Dentistry Domain in IHE.  Several new IHE Denistry members joined in this meeting and developed their very first profile proposal.  The first meeting is later this week, so they'll already have something to discuss.  I didn't plan it that way and neither did they, but we've already ensured that domain will hit the ground running.  I've got another idea for IHE Eye Care on dealing with umpteen imaging devices, and I'll forward that to the cochairs.  Finally, my personal favorite will get a free ride simply because I like it.  The idea is to extend Request for Clinical Guidance (pdf) profile to enable providing feedback to a CDS Service.  The key idea here is that after providing some alternatives, the EHR can send back a response indicating what was done.  That will enable the supplier of the decision support to do a bunch of cool stuff, most notably benchmarking and metrics, but also use that feedback to improve CDS.

After all that, we gave the attendees a tour of the Connectathon floor, and Doug got a personal tour of the floor led by several IHE luminaries.  I tagged along for fun.

All in all, it was a good day.  I did manage to check in with my teams today, and they seem to be mostly on track.

Tuesday, January 18, 2011

The Knack is not the only skill you need

You have all likely seen this video.


I'm in a room filled with people who have the Knack. You know the type. Give them a great big box of stuff that requires assembly, and they begin immediately begin to put it together without reading the instructions.

The problem is, at the end, when there is one screw left over, they don't know what they've missed. So, now they begin goving over the instructions in detail to figure it out. They will and eventually do figure it out, because they know if they don't, something bad could happen.

Remember, I'm in a room full of these people. Their jobs this week are to put together interoperable solutions. The screws that are left over result in failed tests.

I cannot tell you how many times over the past eight years I've read the instructions to someone else, or the specification, or how many times my colleagues have done the same thing. It usually results in a polite "Oh...thank you" and they resolve their issue to move on to the next problem.

The ones I want to keep are the ones who learn the most valuable lesson of this interaction. They start to read the instructions first.

After all, if the solution was so obvious, IHE would not have been asked to solve the problem in the first place.

So, my best advice for this week. Read.

Monday, January 17, 2011

A Virtual Connectathon

Those of you who regularly follow me know where I am this week... The IHE North American Connectathon.  I think that connectathon is one of the coolest events the healthcare industry does, and its because of the collegial atmosphere and get it done attitude that permeates the whole event.  I'll be live-posting on Connectathon more this week, but I wanted to start off the day with an interesting and related exploration.

A couple of days ago, Doug Fridsma (the keynote speaker at the Connectathon conference on Tuesday) commented to me that this is something that should also be available virtually and year-round (he attended the HL7 Working Group meeting which I was also at last week).
Help Needed
I'm gathering all the web commentary on the PCAST report I can find for a submission to the ONC RFI. If you have links that may not be what I have already seen, tweet me or send me an e-mail with it. 

I've been thinking about this topic a little bit, and wondering what a virtual connectathon would look like.  There are a few challenges to overcome to make the connectathon a virtual event, and the first of these is the intensity of the atmosphere.  This year's North American Connectathon includes more than 150 systems (up 25% over last year), which will execute over the course of one week tens of thousands of tests which will be reviewed by a team of more than 50 people.  According to Bill Majurski, about 70% of the registrants will be using XDS in some form.

I recommend that product teams send at least 2 people to connectathon per product being tested, which gives a fixed cost of about two weeks of effort.  You can do it with one (I've been there and done that), but that's a mountain of effort to put on one persons plate.  Teams also put in about 1-3 weeks of effort pretesting each profile (not including development time).  Most companies test more than one profile, and can often take advantage of overlaps in product requirements to reduce the aggregated time.  Even so, it's still a large time committment.  Spreading that effort out in a virtual event over the course of a year reduces the intensity. 

But the intensity is one of the reasons why connectathons are so valuable.  Participants have a week to succeed.  To do so, they MUST work with their partners, sometimes deep into the night.  There is no other choice, and this necessity makes for partnerships not heard of in the real-world.  How, in a virtual event, can we ensure this kind of participation?  Outside this room, these people are often stiff competitors, but inside they are your testing partners. You work face to face with your partners to succeed at this event, sometimes shouting down the row, skyping or talking with cell-phones, while making code changes live.  A success is often celebrated with a beer or dinner later with these same people.

So a virtual connectathon has to have another purpose, and another way to ensure success, than the event I know and love.  It's pretty hard to share a beer virtually, and without the deadline, impossible to get that kind of coordinated effort among competitors.  Some other possibilities come to mind.  One is to have shorter, more frequent regional events.  We've done that for several years.  IHE members attended a number of different events and demonstrations, some of which included connectathon like testing including the VITL Summit, the eHealth Connecticut Demonstration (2008), and PHIN's annual conference.  While it adds value, it's not what I think Doug is asking for.

So what would a virtual, year-round testing event look like?  Who are the stakeholders?  What are the benefits?  What are the costs?  Who would pay for them?

Stakeholders and Benefits
Governments
Readily available testing of healthcare IT that meets regional requirements.
HIE Organizations
An opportunity to test their systems with new products as they become available.
Healthcare Providers
Products that have been tested more recently and frequently than annually.  The ability to test homegrown solutions and integrations.
Healthcare IT Vendors
The ability to test more frequently than annually, the ability to test at much lower cost and intensity of effort, the ability to test with partners that you didn't have the opportunity to test with at connectathon.
Costs
There are a couple of things that go into the cost equation.  You probably need a virtual private network to set up a "Connectathon" like network environment.  You need someone to manage this, assign access, et cetera.  You also need monitors / test proctors and someone to manage them.  Connectathon itself requires a team of 3-4 people to manage all that, plus a team of about 50 monitors.  You could probably get by with a team of 1-2 to manage the virtual environment and manage test results to start off with, but you still need a larger team to proctor the tests. 

The IHE monitoring team is made up of volunteers.  The concentration of time at Connectathon is what makes it possible for many volunteers to participate.  Some of the monitors are friends of friends of IHE who got dragged in once and keep coming back, others are IHE committee chairs or participants, and a few others are contractors working on large projects (e.g., HITSP) who come as part of their work.  Most come to Connectathon because they like the atmosphere, support the work being done, and they also get free travel to Chicago in January.  Some are giving a week of their lives for nothing more than the experience on the Connectathon floor, using up vacation time to boot.  Many are rather skilled IT people, some with very specialized skills.

Something else has to be done to provide value for monitors other than the free travel because there is no free travel once you go virtual, and you've also radically changed the atmosphere.  Because of the diversity of experience, you'd probably need to pay several skilled individuals to do the job, and you'd need to invest in their skills as well.  My guess is that to do as much work as the 50 volunteers do in one week over the course of a year, you'd need to hire 3-6 part-time contractors to do the same work, and you'd also have to spend some time training them, which might also include participation in new IHE work.

I'd ballpark that a virtual connectathon would have a budget of anywhere from a half-million to a million dollars depending upon how you got the monitors.

Paying for It
So, just to make it simple, let's say that the cost was a cool million dollars.  Cheap at twice the price.  How could that be funded?  At $4000 per system you'd need to get 250 systems to participate in the virtual connectathon.  That's more systems than participate in the annual connectathon, and an enrollment likely not to be reached for some time if ever.  I could see maybe 100 systems after two years if the right incentives were present to participate, and in the first year, 25 - 50 systems if you were lucky.

We could maybe cut the networking costs and staffing requirements by getting the state HIE's to supply resources, equipment, et cetera to the effort.  Maybe the RECs which already have developed some requirements of their own could support testing efforts by supplying monitoring and management skillsets in exchange for having a testing environment and audience they could use for their own purposes.  Educational institutions could support testing as well, exchanging student assistance with testing for the training that the virutal connectathon experience provided and the educational credits that the institution offered.  Hmm, those two weren't even in my original list of stakeholders.

We still lose the intenstity of the live event, but that could be supplied (in smaller doses) by other special purpose time driven events.  State HIE X could sponsor an event designed to test conformance of a variety of systems to an Immunization message.  REC Y could sponsor an event designed to test conformance of a variety of systems to their own region's initiatives.  Sponsorship of an event might have its own costs born by the sponsor, with possible additional fees assessed to event participants, but those fees would have to be reasonable. 

I could certainly see the advantage to vendors to be able to have a system connected year round where these sorts of tests could be routinely performed.  It could eliminate a lot of duplicated effort around the country, and could enable many activities not possible in current Connectathons.  Some of those same resources could be used to support other opportunities in education and innovation later, but I wouldn't want to get too defocused in the first year or two.

It's an idea worth persuing further.  If I were on the board IHE USA, I'd be thinking long and hard about this one.  We could make this idea work, and it could shortly become self-sustaining.  It wouldn't be the same as Connectathon, but nothing virtual ever would be. If you happen to be at Connectathon this week and have read this post, I'd be interested in getting your feedback.

Wednesday, January 27, 2010

IHE Product Registry Open for Submissions and other IHE news



IHE Community,

IHE North America Connectathon Sees Expanded Participation
The IHE North America Connectathon, which took place January 11-15 in Chicago, set new records for number of participants, systems tested and successful tests performed. In addition to nearly 500 individual testing participants, more than 120 attendees took part in a one-day conference associated with the testing event. Read more.

Interoperability Showcase at HIMSS10
The annual Interoperability Showcase will be presented at the Healthcare Information and Management Systems Society (HIMSS) 2010 conference March 1-3 in Atlanta, Ga. With 73 participating vendors and organizations, the HIMSS 2010 Interoperability Showcase illustrates how interoperability drives improvements in the quality, safety and efficiency of care. Read more.

Patient Care Device User Handbook for Public Comment
The IHE Patient Care Device domain has released its User Handbook 2010 edition for public comment. Healthcare administrators who makes purchasing decisions, clinical engineers, IT systems analyst and medical technology evaluators will find the handbook a valuable resource. It describes how to use IHE PCD profiles to improve how the integration capabilities of systems and devices are selected, specified, purchased and deployed. Comments are requested by February 12th, 2010. Read the handbook.

Product Registry Open for Submissions

IHE has developed a new resource for developers of healthcare IT systems to publish information about the interoperability capabilities of these systems. The IHE Product Registry will enable vendors to develop and publish IHE Integration Statements for systems that are available commercially or as open source code. Users will be able to browse or search this information by system type, IHE profiles and actors implemented, company name and other criteria. The Product Registry is ready to receive submissions now at http://product-registry.ihe.net/. We also welcome feedback from submitters and users on how the registry might be improved.


The Product Registry will replace the IHE Integration Statement page at http://www.ihe.net/. That page will no longer be maintained. Companies that have published Integration Statements linked to that page are strongly encouraged to publish their information in the Product Registry.




Friday, January 15, 2010

Day 5 and off to Phoenix

On the morning of day 4 you start to get grades (red, yellow, green) for profiles that you've failed, may be failing, or passed.  The morning of day 4 usually has very little red because there isn't much danger of failing yet, but if you don't make any progress on that day on a profile, it goes to red Friday morning.  I woke up to two reds this morning on Day 5 that I didn't understand. 

Check Status Frequently
On tracking it down I was reminded that you need to continually check status.  In this case, one critical path test got paused because of missing information in the logs, without me ever noticing.  Not noticing it, I didn't rerun it so there was no progress yesterday.  Thus a red flag. 

Avoiding Test Failure
In this particular case, the test wasn't clear about what information was expected, but it was easily accessed from my logs, so I resubmitted it.  But, I've seen other systems get tests paused or failed for lack of following instructions.   A complaint I commonly hear from connectathon monitors, managers and profile authors is that reading appears to be a lost art these days.  One of the connectathon monitors wears a shirt whose acronym can be interpreted as Read The Free Manuals.  It's important to read the instructions on the tests and then follow them, and be prepared provide even more information than is asked for just in case.

Have the Right Team
Something to add to my list for success is the team makeup that you send to connectathon.  To be successful a system should have at least one technical expert who can quickly find and correct problems in your application code, and you should  also have someone who is detail oriented manager who can plan how to execute the tests, and track that they've succeeded.  Few systems succeed without both skill sets, and you rarely find them in one person (when you do, keep them around).  If you are sending more than one product, you should also have someone to manage your overall participation.  If your application has several subsystems, you may need more than one technical expert.  It helps to have prior connectathon experience.

I've been fortunate that one of the teams I'm working with has that person with both skill sets, another team that has multiple experts and a manager ensuring execution, a third team that read everything very closely, and the fourth team has multiple experts and plenty of connectathon experience.  We didn't get everything done that we wanted to, but we did get everything done we had planned.  That's a successful connectathon in my book.  Well, off to Phoenix.