Mashup Generation

In my younger days, I played role playing games, wrote fan fiction, and hung out on bulletin boards using my modem and phone in the days of the pre-Internet era.  Today, my eldest daughter role plays while writing serial fan fiction with friends on an internet site that is essentially repurposing the infrastructure used to manage a forum, all on her cell-phone.  She lives in the generation that invented mash-ups, and can take four unrelated concepts, throw them together, and build something not just novel, but also quite usefull.  She and her friends think nothing of spending hours writing stories together over the internet.  And I've read this stuff.  I'd pay real money for some of this in e-book form. They are not only creating their own entertainment, but also learning and practicing great skills, and creating an economy all their own.  I'll show you my stories if you show me yours.

This gives me hope, especially if we can get this generation to apply those same skills to some of the more challenging problems we face.  Imagine if your healthcare providers used an internet forum in real-time to discuss your case.  What would that look like?  It might feel foriegn to doctors of today, but to those in my daughter's generation, it will be as natural as breathing.  If only we can get out of their way.

   Keith

IHE Cardiology Technical Frameworks and Technical Framework Supplements Published

IHE Cardiology Technical Framework Volumes and Technical Framework Supplements Published The IHE Cardiology Technical Committee has published the following Technical Framework Volumes as of August 29, 2013: Volume 1 (CARD TF-1): Integration Profiles Volume 2 (CARD TF-2): Transactions The committee has also published the following supplements to the IHE Cardiology Technical Framework for trial implementation as of August 29, 2013: Displayable Reports (DRPT) Evidence Documents Profiles Cardiology Domain Options: Stress Testing CT/MR Angiography (ED) Image-Enabled Office (IEO) Resting ECG Workflow (REWF) Stress Testing Workflow (STRESS) These profiles may be available for testing at subsequent IHE Connectathons. The documents are available for download at http://ihe.net/Resources/Technical_Frameworks/. Comments on all documents are invited at any time and can be submitted at http://ihe.net/Cardiology_Public_Comments/.

Orienteering

For several reasons I've been working on putting a service oriented face around several interoperability specifications and profiles.  I need to demonstrate an architecture that is readily understandable and which can be composed from/with a variety of off-the-shelf components.  As one who's been developing software and service components for decades, I get quite a bit about what the SOA craze is about.  As a friend and I discussed over the phone today, twenty years ago the buzz was Object Orientation, now it's service orientation, but the compass still points in the same general directions.

I managed somehow to inherit about $200 of Thomas Erl's SOA series of books a couple of years ago.  I've browsed through them a couple of times, but never seriously.  Today, I think I understand why.  I'm more than halfway through Principles of Service Design and am quite frustrated.  It seems that the secret to writing a book about SOA these days is to use a Service Noun Phrase every other sentence (just like I did here).  It may be just that I don't like Erl's writing style, but frankly, I got as much or more out of this 33 page IHE white paper on the topic than I did from the first 300 pages of his book.  I'm glad I didn't buy these books because so much of what I read feels like markitecture, and if not that, common sense.

Last night I had SOA nightmares.  Today I'm feeling a bit better about it, but I'm still struggling to grasp how it is different from what I know already.  For me, the challenge in truly learning something new in the art of software development is in understanding three things:

• what is it that is like what you already knew but has a different name now, 
• which of those things are almost like what you already knew, but is slightly different (and in what way),
• what is truly new.

Once I've figured that out, I can apply it and decide for myself whether the differences matter, and whether the new stuff is really important.  I'll get there, but it can be painful.

And as an added bonus, here is an SOA Buzzword Bingo card for you, just to share some of my frustration.

B	I	N	G	O
Business Logic	Independance	Contract	Governance	Orientation
Abstraction	Discovery	Reuse	Agnostic	Orchestration
Binding	Composable	Service	Granularity	Loose Coupling
Boundary	Inventory	Meta Data	Flexibilty	Taxonomy
Autonomy	Centralization	Policy	Governance	Stateless

Back to School

So today I finished off a bunch of paperwork related to going back to school for me.  I've been accepted to the Biomedical Informatics Program at Oregon Health and Science University.  My faculty adviser will be fellow blogger Bill Hersh, known in blogging circles as the Informatics Professor.  Getting to this stage was quite a bit of work, and involved jumping a number of hoops, given than I'm a non-traditional student.  That's code for I don't have a Bachelors degree.

One of the questions I'm often asked is why I want to do this, especially given that I already teach classes at this level.  I've been a guest-lecturer to MS students in Northeastern's Informatics program and Johns Hokin's MPH degree programs, and have also participated in symposia at Harvard Medical School and at the University of Utah.  In addition, I've written the only text book on the HL7 CDA standard.

I laugh at myself a bit, and I also point at that some of the schools where I've taught won't even let me into their masters' programs. I understand why, and it's not the program or the people involved in it who are at fault. Two deans and one program chair failed where Bill (and I) succeeded.  It's the accreditation process and procedures that are put into place to ensure that we've got quality programs at those schools that don't allow for exceptions (and ensure that everyone gets their pound of flesh).

My first answer is a bit off the wall.  The reason that I want to be here is to learn what my students are learning.  That's actually a pretty good reason when you think about it.  It makes it easier to connect and to understand what they already know (or should know).  The other reason is because while I've got really detailed specialist knowledge, what I don't have is some of the breadth that others do who've been through a program like this.  In my day job, I'll learn it as I go when I realize there is a gap, but this gives me an opportunity to identify a bunch of gaps at once, and concentrate on addressing them.

I hope that in entering this process as late as I am, and as set in my ways as I am, I don't run into the potential dangers of academia.  I expect to be as cantankerous and as challenging a student as I was as an undergraduate (I didn't say I never went to college, just that I never finished).  I just hope that I don't wind up scaring my teachers away.

As I enter into this new distribution of efforts, I'll be stepping back from some other activities.  Recently new cochairs were elected for IHE Patient Care Coordination. For the first time in eight years (yes, it has been than long), I won't be co-chairing a committee in IHE. But I'll still be around and participating.  I will continue on in my role as an HL7 Board Member, and I don't rule out more advanced participation on the HL7 Board in the future.

Social Media for Market Research

I'm not often called on to do market research, but when it falls into my area of expertise, I'm all over it. Back when I first entered the technology field more than two decades ago, it meant being aware of who the right analysts were (e.g., Frost and Sullivan, Gartner, IDC, et cetera), and then talking to your marketing people to get access to the right research.  It also meant being aware of your own market, who your competitors were, and doing some digging.

But how would you find out who the competitors are in a market you don't know quickly?  And when you don't have access to the right market research, or even worse, when you are the first person doing that sort of in depth analysis?

The advent of social media makes some of this a lot easier.  Want to know who works for the competition? Find someone on twitter that you know works for them, and then traverse their links and their friends links. One of those clusters is likely to be a batch of co-workers.  There's a place where you can graph your linked in connections that I don't recall how to find, but what I do remember was that it was a quite accurate reflection of my employment and education history.

Want to know who your competitors are, or the competitors of another business?  Find them on linked in.  Then find past employees of the organization and then where they are now.  There's a pretty good chance (especially in specialized industries) that it will be a competitor. The more specialized the industry, the greater the chance of it being a close competitor.

Want to find out what your competitor is doing technology wise?  Have a look at the technology skills of their employees.  Do they know anything about technology X?  Go look.  How many people on twitter mention X in their profile?  How many followers do they have? What's their Klout score?

Want to find out how much of your market is using Java vs. .Net?  Search for those skills and then filter by companies in your network. Want to know where a competitor has offices?  Find out where their employees are.

How big is the company?  Easy for publicly held firms, just go check their 10-K.  But what about privately held companies?  Is that a 200 person company or a single person consultancy? Locate how many people list them in social media.  Find their Linked-In page and the answer is right there.  If they don't have one, find out how many are on social media, and compare that number to those of similar companies where you do know the size.

Looking at a potential location?  How many people in this city (or state or nation) have these skills?  The right query and filter will answer that for you.  An acquisition?  Same question, different filter.

There's an amazing amount of data in those links.  Some of it is hard and accurate, others fuzzy and gray.
Use it now while you can, because I'll guarantee that eventually you'll have to pay for it.  So get the value out of it while the getting is good.

And remember, anytime someone adds something new to your landscape, understand that there's always something of value that can likely be found underneath, above, inside, beside or behind it.  Even rocks deserve looking under.

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 Gain a Sneak Peak of the Connectathon testing floor. 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 Interoperability Challenges? Download your complimentary eBook- Interoperability for Dummies: IHE Edition. 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

Information Modeling vs. Implementation Representations

I was thinking last night about how HL7 modeling works going back to the RIM, and how the methodology provides a lot of knowledge relevant to the information model, but that knowledge hardly changes in the communications. Then I was contrasting that rather detailed methodology to some simpler approaches.  FHIR for example, provides one or more mappings from a resource to HL7 V2, V3 or other specifications. Then I looked at the VMR Logical Model.

Through all of this I was trying to determine how an XML Implementation Technology Specification might work that would allow the generation of simpler XML for HL7 Version 3 specifications, and potentially tie FHIR resources more formally back to V3 models.  I don't really have a huge need for all this formalism by the way, but my brain likes to play these tricks on me while I'm trying to go to sleep.

I thought about the rules to generate XML from the VMR UML. That was pretty easy. I realized the missing piece was not actually the translation to XML, but rather the linkage back to the RIM.  And then what popped into my head was the idea that UML logical models such as the VMR map back to information models such as the Clinical Statement through a variety of applied patterns or templates that could be described through a (possibly parameterized) stereotype.  The stereotype and parameter values provide the information modeling knowledge that allows for semantic translation back to the HL7 RIM.  The UML model provides the structure that is used for developing the XML or other representation of the content.

You can apply these stereotypes to classes, relationships and attributes of a UML model.  The parameterized stereotype for a class might well establish how one sets an information context from which attributes and relationships of that class in a logical model access information via the reference information model.  For example, I can now take the class representing the FHIR Condition Resource and associate it with the RIM Condition Class via a UML Stereotype.  I can attach to the severity attribute a UML stereotype representing an "Annotation", with parameters indicating that the type of annotation is "Severity" (from an appropriate coding system).  That stereotype can be associated with a RIM model fragment where the content of the severity attribute in the UML model represents the value attribute of an observation class associated with the base observation by the subject of relationship.

Essentially what this allows is the creation of simplified, nearly arbitrary UML logical models, related back to the RIM and so providing full semantic information in the standard.  And while the models can be nearly arbitrary, there are some natural patterns that would appear because they become the easy way to group or relate things together.  One can readily generate XML or other representations from these logical models, for example, as FHIR already does to generate XML or JSON.  And you have full RIM semantics stored in the model, but not necessarily needing to be conveyed in the message because it's knowledge captured in the model.

I touched on this idea that the domain knowledge in the model need not be transmitted in every message briefly back in 2009 in Synthesis, and also a little bit in in A Triangle has Three Sides.  [One of the nice things about having a blog is being able to see where you wrote about similar issues].  We've been struggling with this idea of simplification in HL7 for quite some time.  I think this idea might provide the bridge between current V3, FHIR and CDS artifacts.