Saturday, November 26, 2005

List of Problem Areas

A more precise specification of areas of focus reads as follows:
  • problems of documentation in relation to the factors of intelligibility by the human beings who must create software and refined messages and domain information models on its basis;

  • the steep learning curve: does HL7 V3 have the ability of to be taught and therefore engaged with, and used (evidence so far in this category is that it is highly problematic, and the perceived complexity is a major barrier to engagement and easy use)?

  • problems of implementation: the decision by HL7 to adopt the new RIM-based methodology was adopted already in 1997, and versions of the RIM were available already in 1999; why, after six years of effort, and considerable investment, is it so difficult to name even one successful large-scale implementation of V3?

  • problems of quality of the HL7v3 artifacts and methods in terms of whether they convey intended (or even sensible) meanings and can be used with well-designed ontologies for functions like computerised decision support (and in general for the sorts of sophisticated tasks which will increasingly become necessary with the advance of genomics-based biomedical (informatics) research);

  • external problems concerning the relationship of the HL7 V3 corpus to the outside world; is the very methodology of HL7 V3 appropriate to the world as it is today, with increasing migration towards web-based technology?

  • problems of internal consistency of the HL7 RIM from an ontological point of view: for while the RIM is presented officially as an information model (so that the instances of its classes would be information/data items), its documentation is formulated in such a way that the examples given are in very many cases examples not of information about real objects / processes but of these real objects / processes themselves;

  • software problems, for example concerning the degree to which shortfalls in consistency and clarity of documentation may lead to the further problem of message and software developers creating incompatible / buggy / unworkable solutions; is HL7 V3 able to support the economic production of maintainable, reusable and extendible software?

  • functional problems concerning the fitness of v3 for its claimed purposes (messaging and apparently EHR and decision support at least); here we will attempt a comparison of what v3 actually offers with current requirements in the various functional areas of the health computing platform -- to what degree is V3 appropriate for satisfying well-known requirenments in clinical informatics?

  • technical probems concerning the quality of HL7v3 with respect to accepted practice in information modelling, object-orientation, software engineering and data management. Items in this category talk about whether v3 supports the construction of good quality, re-usable software, integration into modern computing infrastructures and development environments;

  • problems of usability of the V3 domain models (RMIMs etc) by specialists in the corresponding domains, and problems relating to the ability of clinical and other domain specialists to engage directly, given the specific methodology of HL7 V3 for producing new specialized information models for each new domain, models which differ in unanticipatable ways from the RIM which serves as their starting point;

  • problems of appropriateness: to what degree is HL7 V3 specifically appropriate to the US case and to what degree can it be applied in other countries, where issues of third party invoicing play a less central role?

  • terminology problems relating to the ability of HL7 V3 to integrate properly with clinical terminologies such as SNOMED CT;

  • problems with the HL7 business model: is there some conflict of interest involved in the fact that those, such as consultants, who stand to benefit from overly complex standards or unclearly formulated documentation (and from the fact that documentation is not publicly available for peer review by the wider community), are also involved in the balloting process which determines what the standards and documentation should be?

  • problems with HL7 governance processes: decisions on modifications to HL7 standards are based on a balloting procedure involving a number of distinct constituencies, which means that any change must be slow, and this may be problematic in an age of rapid technological change; are those members of the relevant constituencies working with new technologies able to influence the development of HL7 V3 in a timely fashion?

No comments: