Saturday, June 23, 2012

Oracle v. Google: Opening the Closed HL7 Standard (including CDA) ?

Summary: HL7 is a closed standard; HL7 claims to require (expensive) membership to implement its standards, including CDA; the Oracle v. Google ruling that API's are not protected by copyright suggests that HL7 may have no legal basis to prevent implementations by non-members or to extort a fee; but until this is clarified, perhaps CDA should be avoided in lieu of more open alternatives.

Long Version.

Unlike the DICOM standard, whose governing body requires no fee for implementation, the HL7 family of standards (including V.2, V.3 and CDA, amongst others) are not "open standards" in this respect. In particular, the HL7 organization that publishes the standards currently states quite explicitly that organizational (not individual) membership is required in order to "use the material" (HL7 International IP Policy). The cost is decidedly non-trivial, requiring a continued annual contribution of between $1260 - $19,635 (HL7 Membership).

There is not universal consensus about what exactly the definition of an "open standard" is, and how it relates to the matter of fees; this is well summarized in the Wikipedia entry on the matter. Fees for use can be needed in two contexts, as fees to the organization in control of the standard, and as royalty-fees for patents. The European Union definition, for example, precludes the charging of fees of either type; the same goes for the Open Source Initiative's definition, which further requires that the standard also be freely available. 

Since many (if not the majority) of contributors to activities like DICOM, HL7 and IHE are large organizations, and since the membership or fees demanded by HL7 pale in comparison with other costs (like that of EHR certification for Meaningful Use in the US), this has not been a very big concern to decision makers. Just as most global technology companies are not that concerned about patent issues, being participants in patent portfolio sharing cabals, it has sometimes been difficult to promote the case for openness, when a conflict with convenience or expediency arises. As a consequence, the criticality of this issue for open source software developers, non-profit organizations and small users is routinely overlooked.

CDA is a case in point; both IHE, and more recently DICOM, have been nonchalantly pursuing a course of encouraging the use of CDA, and developing profiles (or what HL7 calls "implementation guides") that rely on the underlying CDA mechanisms, without some of us realizing, frankly, that we were building upon an inherently closed standard. The problem has been compounded by the adoption by the ONC Healthcare IT Standards Committee in the US (in the context of Meaningful Use), and in other activities like the European cross-border epSOS pilot project. Indeed, the ONC Proposed Rule for the Phase 2 of Meaningful Use contains language that would preclude the use of "competitors" to CDA for encoding of patient summaries (you recall the bitter fight between HL7 and ASTM over CCD versus CCR).

What HL7 International thinks about the interpretation of their IP Policy with respect to CDA implementation is explicitly reiterated in this response, "Questions & Answers on the use of HL7 CDA and required licensing".

Obviously, it would be unfortunate if there was to be discrimination in the market place against smaller participants (both implementers and users), as a consequence of imposing a mandatory requirement to use fee-based standards. Surely this is not the intent of the policy makers; perhaps they may not have been sensitized to this concern, though this would be surprising, given the sophistication of the stakeholders.

I am not involved in HL7 politics or administration, so I have no insight into their motivation or their future plans. I have heard that they are considering changes to their policy, but whether it is to make things better and relax these constraints, or to make things worse in order to maximize their revenue stream, I have no idea.

Some folks pointed out to me though, that there may be hope, regardless of HL7's intent or desire, in the form of the recent order from the court in the case of Oracle v. Google. You may recall that this litigation was in part related to the independent Android implementation of a sub-set of the documented Java API's provided by Oracle. A copy of the order itself is available as document "Case3:10-cv-03561-WHA Document1202: Order Re Copyrightability of Certain Replicated Elements of the Java Application Programming Interface". Commentary on it can be read in several places, such as in John Harris's article "Judge in Oracle v. Google Case Rules that APIs are Not Copyrightable", in which he notes "... this is not really a new result ... this has been the law for quite some time, until the API copyrightability question was squarely raised in this case". The question of what subject matter is or is not copyrightable in the US is apparently explicitly defined in "17 USC § 102 - Subject matter of copyright: In general", which states in (b) "in no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work".

That definition would seem to squarely encompass standards like HL7, including CDA; though I am no lawyer, and have not consulted one, it would reassure me if were planning on implementing any part of HL7 in my own open source code, or using someone else's implementation in a production environment, and couldn't justify the non-trivial expense of joining HL7 as an organizational member. I am not sure wherein lies the legal basis of HL7's claim of a right to restrict the "use of the material".

That said, since there are truly open alternatives to CDA, until HL7 clarifies the situation in a satisfactory manner, should one consider avoiding CDA altogether? After all, regardless of the merits of any legal question, one hardly wants to get in a legal wrangle with a large organization, and since the policy makers at a national level seem to have abrogated their responsibility to select only open standards, it males sense to look for alternative standards that are open.

Since the standards for the "payload" can largely be separated from standards for the exchange and workflow management, (e.g., XDS, XDR or DIRECT are just useful for PDF, text, or any XML document, not just CDA), there is an opportunity to jump off the CDA bandwagon (juggernaut). Indeed CCR was just such a deviation (that the HL7 folks would no doubt was rather forgotten about sooner rather than later).

One interesting possibility is the CE/ISO 13606 (OpenEHR extract); since this is an ISO standard, it is not free to obtain the specification from CEN or ISO (like HL7 and ASTM, CEN and ISO also charge for copies of their standards, unlike DICOM, IETF or W3C), but it is free to implement, and (unofficial) XML schemas can be obtained from the EN 13606 Association website, and "last drafts" of the CEN standards may be available with a Google search. Charging a "nominal fee" for access to the text of a standard is permitted by some Open Standard definitions (such as in the European Interoperability Framework) though not others (such as the Open Source Initiative). There is an insightful UK NHS Connecting for Health report about "Investigating implementing CEN 13606 with HL7 V3 and SNOMED CT".

Since I am not really involved at all in this EHR and CDA stuff, and my primary interest remains radiology imaging and hence the imaging report, I cannot speak to the practicality of CDA alternatives, and to what extent the issues may be, but they certainly seem to be worth exploring.

This matter of HL7 fees for use came up at a DICOM WG 10 (Strategic Planning) meeting recently; a summary of the discussion can be found in the minutes. Not recorded in the minutes, but identified by one participant, was the need for care with respect to contributing material developed  in a DICOM context (such as radiology report templates), that was then made available to HL7 for joint publication; at the very least, any material developed on the joint DICOM-HL7 group, WG 20, should be accompanied by language indicating that it must remain free for use and cannot be restricted by HL7 when jointly published. Likewise, though DICOM WG-8 has been encouraged to focus its report template standardization efforts related to the RSNA reporting initiative, on CDA encoding, this position may need to be either reconsidered, or the templates produced in a manner such that they can be encoded in other open standards rather than CDA.

At a national level, this is similar to the problem with SNOMED, which also was not "free" for general use; again one wonders whether they have the legal right to restrict use, since SNOMED is all about "concepts", which are explicitly excluded from copyright protection under 17 USC § 102. Regardless, for US use, the NLM "paid them off" with a $32.4 million five year license (them being CAP), and now pays an annual fee of about $6 million to IHTSDO, which now owns SNOMED. My reason for mentioning this, is that it may have set a precedent for well-established closed standards organizations extorting non-trivial sums of money from national governments, and perhaps that is what HL7 International is hoping for. It also doesn't help international users.

From my perspective, the best outcome would be for HL7 to back away from this position, and to allow anyone to implement any of their standards royalty-free anywhere. Indeed, anything less than that would seem to me to be a strong incentive to lobby against using CDA at all, and seeking out a replacement.

David


13 comments:

Martin Peacock said...

It should be noted that a similar (previous) ruling applies in EU as well as US. How 'final' either of them are is perhaps open to question as O agreed to damages from G of $0 with the *apparent* intention to appeal.

Having followed the OvG case for a little while (as well as others - copyright and patent - that other players particularly in the 'mobile' space are involved in) - it seems (IANAL) that some of the reason (or justification) is in that timely defense of one's IP is necessary for the continued validity of that IP.

In that sense, the HL7 position is both legally and morally untenable. There are (as we all know) thousands of unchallenged HL7 implementations in in-house and open source developments (not to mention small vendors) that would undermine any legal position HL7 ever thought it had.

In the meantime, strategic decisions on data formats are a tough call. *IF* HL7 open up fully in the next wee while then it can be a good call that CDA is the way forward. If not - there is inevitably additional risk involved.

There are obviously lots of good (and bad) reasons why HL7, IHE and DICOM move so slowly, but this is one instance where the guys in HL7 need to shift into second.

Grahame Grieve said...

Hi David

IANAL either. But the copyright on CDA isn't a copyright on the process of patient care or summarisation, but on the names of the CDA elements (for instance). I don't see how your argument has any water.

On the other hand, HL7 is getting out of first gear:
http://hl7.org/fhir/

David Clunie said...

Hi Grahame

To quote from Judge Alsup's ruling:

"copyright protection never extends to names or short phrases as a matter of law"

so presumably this applies to the names of XML elements, for example.

Furthermore, with respect to the entire definition of the CDA schema and its rules beyond the schema, which is analogous to an API:

"The overall name tree, of course, has creative elements but it is also a precise command structure — a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability."

David

PS. FHIR is potentially cool and there are a number of other HL7 pilot projects that have more flexible licenses, but the bottom line remains, that for now, HL7's position on critical stuff like CDA is recalcitrant.

Grahame Grieve said...

"analogous to an API"? Sounds like fun for a lawyer.

Of course, all this stuff has to be paid for. You can't develop a spec for free. A clear majority of HL7 members would rather the spec was free, but transitioning business models is dangerous. How is Dicom funded?

Diego B. said...

Just as a clarification, only part 2 of EN13606 (Archetype Definition Language, ADL) is also shared with openEHR. The extract, Reference Model, data types, etc. are different

David Clunie said...

DICOM is funded by membership too (of DICOM +/- NEMA), but it is completely voluntary, and anyone can implement it whether they are a member or not.

The logic behind this is that those who are members, and hence subsidize the standard for everyone's benefit, gain from widespread adoption even though there are "free riders". As in the Open Source community, the free rider phenomenon is not a problem but a benefit.

DICOM would never have been implemented if it were not free and open.

Arguably, HL7 V2 would never have been implemented if it had not been free originally too (despite the revisionist history), and was not still perceived largely to be so and the IP policy ignored.

Like internet and web standards, if major players want interoperability enough, they just get together and do it and share it; they don't have to fund a lot of extraneous activities.

This is not generosity, it is enlightened self-interest.

David

The DICOM standard itself is also distributed for free, and sale of the standard is not a revenue stream either.

Grahame Grieve said...

"The logic behind this is that those who are members, and hence subsidize the standard for everyone's benefit, gain from widespread adoption"

I'm not entirely sure that this same argument applies to the HL7 community the way it applies to DICOM. Certainly, the business drivers are rather different, no?

David Clunie said...

I think the business drivers are exactly the same, just like any other IT standards, though I would be interested to hear why you think the drivers are are different.

Closed standards have no place and no future in 21st Century IT, in healthcare or any other industry.

David

Grahame Grieve said...

Well, personally, I agree that closed standards have no place. That's why I worked so hard to make fhir happen. However, I'd characterize the dicom as dominated by a small set of large hardware vendors for whom interoperability offers increased size of he total pie. I do not think that this true of hl7, by and large. While there are some members for whom batter interoperability is a business benefit, there are many who aren't. On the other hand, it's not like dicom offers ease of use - and that's always seemed like a business goal of he players - also different to hl7

David Clunie said...

FYI, the HL7 International Response to the UK Cabinet Office Open Standards Consultation is available here, as discussed on the UK Imaging Informatics board here.

One of their comments that I find most surprising is their claim that there are no large companies willing to sustain HL7 voluntarily, despite the involvement of well known companies whose revenue is measure in the billions; I quite some examples in the UK forum. And I am not taking about GE.

Jacques Fauquex said...

As stated and well-known, DICOM is an open Standard. Part 20 of the Standard, pages 57ff publishes a CDA Basic Imaging Report (BIR), which is the counter part of an equivalent DICOM Structured Report. All APIs are described carefully, since the equivalence was the purpose of the authors.
With DICOM Standard part 20, one can create DICOM Structured Reports and be confident that they can be translated into corresponding CDA documents when required.
But there is another and I think more interesting way to implement BIR archiving and communication, namely by enclosing the BIR CDA into a DICOM encapsulated CDA object.
I am about to publish an open source way to do that and wonder if, legally speaking, BIR belongs to the DICOM Open standard, or is copyright-protected by HL7?

Keith Boone said...

So where do we stand today David?

David Clunie said...

HL7 changed to a more open policy, and no longer attempts to restrict use to fee-paying members. So, one no longer has to avoid CDA for that reason.

I don't know if there has been further legal precedent established with respect to whether a publisher of a standard or API can legally restrict its use.