So it seems that Facebook is trying to force Timeline on everybody. With all due respect, but this is plain stupid. I do not want to have a timeline, ever. I will try to stop this, but if they go through with this, I will likely end my presence there.
Timeline? No way!
Moving the Town Forward
As indicated earlier, I am participating in my town’s information systems advisory board as a chair. Our proposal to move forward with a strategy to modernize the IT assets of the town received a big boost last night, when the Town Meeting approved an article to move forward with an initial assessment of the IT environment. The way ahead will be discussed in the next ISAC meeting, but we have indicated in the meeting last night, that we want to put out an RFP for this initial activity.
Review of the week at HL7
This week was my first as SOA Working Group co-chair, and interesting it was:
- hData was confirmed to be published as a DSTU with the reconciliation package posted and the specification out. This really wraps up the first stage of standardization with OMG and HL7 now having the respective specifications in early adopters mode. The next step will now be to move ahead, try them out, and fix all remaining kinks.
- With hData, FHIR (aka RFH), and CIMI pushing further into the direction of exchanging simplified partial model graphs, it becomes really important to fully understand and advertise the implications of services in healthcare. While documents and messages have their established place in the world of health IT, services can enable a much more fine-grained level of access to clinical information.
- In such a service context, more granular access restrictions on individual data elements or partial graphs can be realized through element or paragraph-level tagging of data. The tags can describe an elements level of sensitivity or establish special information compartment e.g. for Title 38 categories.
- CTS2, the Cross Paradigm Interoperability Implementation Guide for Immunizations (CPIIGI – or ‘cross piggy’), and of course FHIR also had a pretty successful showing at the meeting.
Next steps are to create the ballot material for the Medication Statement Service, likely using the RMIM for Medication Statements and perhaps even the Medication Administration as payload. Furthermore, Grahame and I are scheduled to meet in mid-February to discuss how FHIR can create hData Content Profiles for FHIR resources, harmonizing these two approaches. Furthermore, I will work with John to discuss how the emerging IHE for mobile activities integrate with hData. And last, but certainly not least, I will hopefully get the chance to work with Mike on Data tagging for Health IT. This activity would be really great, since it would tie a number of different projects I am working on together.
Services vs. Messages and Documents Epiphany
One of the big takeaways for me from this January HL7 meeting is a much better realization how the organization sees clinical documents and messages, and how they relate to distributed services. What I did not realize was how the terms “message” and “document” have a very special meaning in HL7. Specifically, messages and documents in HL7 are expected to establish the context of the exchange, based on the data and metadata found in the message or document wrappers.
In the past, I have made the mistake of talking about simplified content for hData at the leaf resources (“Section Documents” in hData lingo), and reference to this content using terms like “document” or “document parts”. This prompted strong opposition from CDA supporters, who claimed that “document parts” would be inherently unsafe, since they might leave out critically necessary context information. As such, any document or message moderated health IT exchange cannot simplify its content model without performing a “no-harm” analysis.
This is not true for a service-based exchange: the service contract and deployment parameters are the overriding functions that establish the context for any given client-service interaction. A very good example for illustrating this is sending textual information to your political representative: To get information to Senator Alice, you can do this by sending a RFC 822 compliant string of characters (i.e. “To: senator.alice@example.com …”), but for Senator Bob you can use a web application that offers a textbox for sending your letter. The former approach is akin to a V3 message, the latter is more like RLUS/hData services.
Simplification
It now gets interesting when you take the RFC 822 formatted message to Senator Alice and paste it into Senator Bob’s textbox, i.e. you use the service to transport the message. The message will – obviously – not be sent to Senator Alice, but instead end up on Senator Bob’s desk. While this simplified analogy leaves out some details, it shows how metadata for one exchange mechanism are not necessary for another. Any different assumption may lead to unexpected (and most often undesired) results.
As a result, service are -other than messages or documents- able to exchange partial clinical model graphs without needing to include wrappers provided by standards like HL7 V3 or CDA. With proper documentation in the service contract, the wirelevel serializations of these graphs can be made relatively simple, so that standard code development tools (including things like SimpleXML) do not get tripped by the complexity of the format.
DLP and Data Tagging in Health IT
When reading Henk’s thoughts on DLP, I have to concur that DLP must go beyond simple dirty word filtering and similar technical attempts. DLP properly done must include a comprehensive scheme to protect proprietary information that should likely include a data tagging and labeling strategy. Tagging and labeling of information is reasonably well understood, and – essentially – also a prerequisite for mandatory access control.
Interestingly enough, the HL7 Security WG has started to think along the lines of data labeling and tagging to enable data separation for privacy. Mike Davis presented yesterday a proposal that would introduce a tagging and labeling scheme akin to the information control systems commonly found in the intelligence community. It includes the concepts of classification labels, aligned with the CDA confidentiality codes. In addition Mike also attempted to map the concept of compartmentalization to a Need-To-Know principle aligned with the more restrictive information categories such as the information identified in U.S. Title 38 (Drug abuse, Sickle Cell, etc.).
While the current momentum for data tagging in HL7 is largely focused on access control, it would be nice to see more DLP systems deployed in healthcare environment, using these emerging concepts.
WordPress Migration – Part 2
Next steps that I was able to complete was to properly design the look & feel of the site and add all the social media plugins that I have been missing out on. Twitter, social bookmarks, etc. seem to work reasonably, and I am hoping to re-attract any traffic I have lost. I have also tried to follow common directions on implementing redirection for the migration using the Redirection plugin, but results seem to be mixed at best. Also, I have started to point the of blog.beuchelt.org address back to blog.beuchelt.com, and that work ok for the base address.
The final steps will be to finalize the redirection problem, and ensure that old uploaded data is actually available on the new site.
Quick hData update
Finalizing the recent series of events, the hData specs have achieved a major milestone: the HL7 hData Record Format was approved to be published as a Draft Standard for Trial Use (DSTU), completing the HL7 project setup to achieve this goal. Also, the OMG hData REST Binding for RLUS is now a Beta standard with a Finalization Task Force in place.
So what does this mean? The entire suite of hData specifications has now completed a full peer-review within their respective standards body, and has been adopted by the organizations. As such, they are on their way to be fully accredited standards within the Health IT community.
But, what’s next? Obviously, we want to finalize the standards and take them to become fully normative standards. To achieve this, we will need to monitor how implementations work in the field, and what issues arise. Also, we will need to use hData in the context of actual use cases. In a first step, the Pharmacy and SOA working groups at HL7 have agreed to standardize an hData Content Profile for Medication Statements, thus making this important product available to RESTful Health IT service developers. Also, various people have indicated that JSON representations of Continuity of Care information can be very useful.
Townie IT
While I am nominally a member of my town’s “Information Systems Advisory Committee” (ISAC) for more than 2 years, only recently we have been meeting more frequently. There is a dire need in the town to modernize the IT systems and take them to the 21st century (like my blog – thanks for that Tweet, Pat 
), and the town administration is now getting serious about it. This is a new and interesting challenge for me, since I have not worked on small(er) IT environments for some time now. Adding fun to the obvious resource constrains is the current situation, where not only the school system has developed their own, largely independent IT landscape, but all major department like Police, Fire, Public Works, and Library are happily walking in opposite directions.
Pulling all this together will require some significant work, but the benefits are obvious:
- Better services for citizens of the town
- Cost savings from pooling resources and better utilization
- Targeted investments for future projects
- Improved security posture, especially in the light of recent attacks against towns and schools.
In the next few days, ISAC will present its ideas to the town’s Ways and Means committee and – with their blessing – to the Town Meeting.
WordPress Migration – Part 1
I started today a migration from my ancient dasBlog blog to WordPress. This was overdue, but work and personal life did nate make this easy. Right now I am halfway done, and things are starting to appear at this site, thanks to A Little Blog and the BlogML folks. There will be much more work, but the worst seems over.
hData Specifications Standardization Update
hData has had two quite successful weeks:
- Last week, the HL7 hData Record Format version 1 successfully passed DSTU (Draft Standard for Trial Use) ballot. This is a major step towards broad adoption of hData as an international standard. In addition, the HL7 Pharmacy WG decided to start working on a joint project with the SOA WG to create an hData Content Profile for medication history, as a building block for a future ordering service. With the expected increased expectation for adoption, the creation of a project to move hData to a normative standard is now realistic.
- Today, the OMG TC voted to issue the hData REST Binding for RLUS RFC for the mandatory 60 day comment period. It is expected that the OMG will adopt this RFC as an alpha standard at the December TC meeting, and form a Finalization Task Force to move this specification to a formal standard.
This makes hData one of the first standard service frameworks for clinical services that fully supports a RESTful architectural approach. Since there are a number of other approaches currently looking into using basic HTTP services to exchange clinical information (as well as a much broader move to better integrate REST services into an enterprise architecture approach), hData can help creating the necessary underlying foundation for this fabric.
