For myself, I really do not like OIDs at all (here comes the opinionated self back to the surface): OIDs and many similar identifiers carry information, but are not resolvable without a lot of pain. For example, each of the numbers in the OID is assigned to some sort of entity, like an organization (like the ITU-T), a country (like the USA), or a thing (the Internet). The dot notation is organized hierarchically, implying that you can “walk” that tree. Great. But you cannot, since each node owner (e.g. the owner of 1.3 = ISO Identified Org) can setup a registry for this branch and make it accessible to the wold, but the owner of e.g. 1.3.24 = DEC will probably not make their entire subtree resolvable to everyone. As such, if you encounter (hypothetically) an OID of value 1.3.24.0.1000, good luck figuring out what that may ever have meant. Even if HP wanted to make this available, it would take some heroic effort to find a public registry for 1.3.24 and then resolve this to some HP property.

On the other side, there are identifiers like IPv4 addresses which are – thanks to the wisdom of CIDR – essentially free of any special semantics: they are simply numbers. IPv6 does even a better job in making sure that the components of an IP address are not overloaded with meaning.

Finally, there are URLs that point to resources – and they have the wonderful feature that they can be fully resolved. If you are presented with a URL, you can immediately figure out where to go on the network to get to that resource. The path to the resource may not be clear (there could be firewalls or even air gaps in the way), but – in principle – your URL tells you exactly what to do if you want to get to the resource. Now, given that a URL points to exactly one resource, they make ideal identifier: they are unique (thanks to DNS and HTTP), they may carry some reasonable meaning (e.g. http://example.com/customers/1234/?invoice=9876 is pretty suggestive), and they can be resolvable into a representation of the resource.

Pick you own favorite.

To address the problem, NIST has provided the SP 800-30 risk management process for some time now. And while high-level threats are very application specific, the National Vulnerability Database provides a low-level overview for what vulnerabilities a threat actor could attempt to exploit.

• 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.

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.

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.

The final steps will be to finalize the redirection problem, and ensure that old uploaded data is actually available on the new site.

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.

• 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.