HINZ_2012_CDA_Implementations_Leasons_Learnt.ppt

Editor's Notes

• #2: Clinical documentation is used throughout healthcare to describe care provided to a patient, communicate essential information between healthcare providers and to maintain a patient medical record. Is anyone unfamiliar with CDA ? If so…Clinical Document Architecture, “the documentation of clinical observations and services”. In the NZ Health Sector, the initial use has centred on the communication, or messaging, function and CDA documents are the common currency of information exchange (‘payload’) in the Reference Architecture for Interoperability (RAI), and now an approved Health Information Standards Organisation (HISO) standard. The HL7 CDA standard is one of the 3 pillars of the NZ Health Sectors RAI and the first to see widespread practical use. The first nationwide NZ project to use CDA was General Practitioner to General Practitioner (GP2GP) Patient Record Transfers, now in full production, closely followed by the eDischarge Summary Trial and now the ePrescribing Service Pilot. These implementations have exposed a number of challenges, with regard to using CDA to facilitate semantic interoperability between diverse, commercial, eHealth applications, notably the Practice Management Systems (PMS) used in Primary Care. This presentation will explore the challenges encountered in the early implementations, the key strategies and techniques used to meet them and the lessons learnt in the process. In particular, the development and use of common data models and a shared software component, the NZ CDA Toolkit, to generate and consume CDA instances from PMS will be examined.
• #3: CDA is an international standard – based on HL7 v3 data types and the RIM – for the production of all clinical documents. This necessitates a highly flexible design and, as such, one that is open to diverse interpretations and implementation standards. Furthermore, to the best of the author’s knowledge, no commercial eHealth application in the NZ market place natively uses the HL7 v3 RIM - or the constrained version R-MIM (Restricted Meta-Information Model) implemented by CDA - at any level; persistence, application or presentation (user interface). Hence the overarching problem to be solved was – how should CDA be implemented in NZ, with particular regard to the first round of interoperability projects mandated by the National Health IT Plan [5]. These challenges can be grouped into six broad classifications: Data Modelling. Converting the ‘traditional’ PMS clinical data models of Patient Demographics, Allergies and Alerts, Encounters, Medications, Observations, Tests, Vitals, Immunisations, Problems, Procedures, Maternity, Documents, etc into the RIM backbone ‘clinical statement model’ of an Entity fulfilling a Role Participating in an Act. In particular, the constraint of only six types of Act – Encounter, Procedure, Observation, Substance Administration, Document and Supply. This task is compounded by the need to convert relational data structures to the hierarchical Extensible Markup Language (XML) [6] format used by CDA which uses the concept of Entry Relationships to link clinical statements. On top of this is the requirement to achieve semantic interoperability when passing data between disparate PMS systems which implement varying levels of data normalisation and different clinical coding systems. Data Typing. CDA implements the HL7 v3 Data Types many of which are composite classes of standard data types and have no direct equivalent in PMS systems – examples of this are Concept Descriptors (CD = Codes) and Instance Identifiers (II ] IDs). Furthermore, whereas most software environments implement only a single expression of a null value, each HL7 v3 Data Type contains a nullFlavor property, which supports up to 11 ways to indicate why a value is empty! Validation. CDA uses the industry standard XML format and hence individual documents can be validated against an XML Schema (XSD). However, although this technique provides structural validation – and a limited amount of content validation – it is restricted by the limitations inherent in the XSD technology: these include the inability to specify a choice of attribute values; a set of elements and attributes; or to vary the content model based on the value of an element or attribute (co-occurrence, i.e. if…then, constraints). In other words, XSD offers only limited ‘business’ level validation.An additional problem is that the values permitted by some HL7 v3 data types are constrained by external coding sets – notably Units which must come from the Unified Code for Units of Measurement [7] – that are too large to be placed in an XML validation artefact; and require the use of external tools or custom software implementations. As a consequence, it has been estimated that only 20% of CDA instances produced worldwide are fully compliant [8].Content validation is also required, and this is based on Implementation Guides (IG) and Templates. However as neither of these artefacts can be directly applied, at the machine level, to enforce constraints against a CDA document – a choice has to be made whether to assert IG and Template rules using XML Schematron [9] and/or custom-built software components. NZ-specific requirements. As an international standard, CDA attempts to encapsulate a maximum set of clinically-related data elements, but in practice this is an impossible task. For example, the Patient Demographics class, rendered in the CDA Header, contains only a single ethnicity and no corresponding property for the NZ-specific concepts of Iwi and Hapu. Presentation. CDA documents contain a human-readable element, notably a Text Section that implements a subset of HTML that can be displayed in a browser using Extensible Stylesheet Language Transformations (XSLT) [10]. This begs the questions which styles to use and whether a generic, or project-specific, stylesheet should be used. Document Transport. CDA is a document, not a messaging standard; raising the issue of how one should transmit a CDA document, and any external attachments, from one Healthcare Facility to another.
• #4: The above challenges were first encountered in the GP2GP Project. As a continuity of care requirement, involving the transfer of an entire patient record from one healthcare provider to another, this represented a large-scale implementation of CDA; with each individual PMS vendor needing to interpret the substantial, and highly complex, Implementation Guide in an absolutely identical way. To resolve the relevant technical, and financial, implications of this, two solutions were adopted – the development of a new shared Data Model and a common software component (NZ CDA Toolkit) to facilitate the creation, packaging and consumption of GP2GP CDA documents. These solutions were subsequently adopted in the implementations of CDA by the eDischarge Summary and ePrescribing projects.
• #5: The development of a new, and common, data model solved many of the Data Modelling and Typing challenges – as well as the overall issue of converting the logical data model outlined in the GP2GP Business Requirements to a physical data model fully understood, and agreed upon, by each PMS Vendor. It was also the bridge that facilitated the grouping of the agreed clinical data elements into CDA Sections (Encounters, Medications, Problems, etc) using the internationally-adopted Continuity of Care Record (CCR) and Continuity of Care Document (CCD) [11] standards – this approach was subsequently mandated by the RAI. The use of an international standard helped to fuse many of the differences between the data models of the participating vendors, but there was one overarching concern in matching the relative granularity of these models. Should the highest (atomic, coded, data elements), or lowest (free text) common denominator be implemented and what about elements – and even entire sections – implemented by only one, or two, vendors? In principle it was decided to implement the most structured, atomised, versions (“don’t exclude anything that any one of us has” in the words of one vendor) of each CCR/CCD Section, and this goal was facilitated by the establishment of the following principles:- No mandatory Sections. In several cases where no vendor implemented an atomic data model (e.g. Advance Directives) CDA Level 2 (human-readable text only) was used – in all of the other instances CDA Level 3 (fully atomised, human and machine-readable data) was used. Very few mandatory data elements – mainly patient and record identifiers - and all coded properties must contain an alternative free text property (fortunately, a valid implementation of the HL7 v3 CD type). Any number of Name-Value Pair (NVP) properties can be added to an individual (Level 3 Section) Entry. This meets the requirement for the model to be both fully comprehensive and infinitely extensible.   Another key task in the modelling was how to implement the common links between individual Entries (database rows in relational database terms) – this was achieved by the following:- The facility to link entries in various other sections to an Encounter Entry (e.g. Medications, Problems & Procedures). External Documents can be linked to any individual (Level 3 Section) Entry.   The appropriate parts of this Data Model, plus project-specific additions, were carried forward to the eDischarge Summary and ePrescribing Data Models with some general exceptions. No NVP attributes in more tightly-constrained models Mandatory numeric values in order-related elements (e.g. ePrescribing is an ordering system and, as such must contain atomic, numeric, values for quantities and not textual expressions such as “a week’s worth”)
• #6: The Toolkit is a class library that is incorporated into each individual PMS. The technical details are outside the scope of this Paper; suffice to say that - in software architecture terms - it is a client adapter, providing a common interface to an internally hidden (‘black box’) implementation (mapping of the Data Model to CDA, and vice versa). In addition to exposing an object-oriented view of the relevant Data Model, the major function of the Toolkit is to provide a common approach to the creation (rendering), consumption (parsing), validation and packaging of CDA documents. In particular, the following challenges were resolved without consuming the resources of all the participating vendors NZ-specific patient demographic details (additional ethnicities, Iwi and Hapu) are placed in an ‘Additional Demographic Information Section’. An alternative would have been to implement CDA Header Extensions, but these have to be removed before CDA Schema validation is performed and cannot be processed by the ‘standard’ CDA Stylesheet. The translation of individual elements from the Data Model into CDA elements and attributes – which class of Act to use; what’s the difference between an act and an observation. Which Coding System and Code should be used to identify each individual data value that’s not in an Act Class? Nullflavor is implemented internally by the Toolkit, when a (non mandatory) Coded property is left unpopulated, it is not directly exposed to the client system. Constant values for Coded Identifiers (i.e. Constants.SNOMED is a lot easier for Vendors to enter as Code System rather than 2.16.840.1.113883.6.96). Validation; CDA Schema validation is implemented by the Toolkit, along with Implementation Guide and Template level validation and a restricted sub-set of HL7 v3 data type checks Removal of certain HL7 v3 and CDA ‘pain points’. There appeared to be little or no point in forcing the implementation of some HL7 v3 standards, notably UCUM-compliant units, particularly given the crucial maxim that the Toolkit cannot modify any data values passed to it by a PMS. This pragmatic approach to CDA validation was recently discussed by HL7expert Grahame Grieve in a recent post on his Health Intersections Blog [12]. Packaging – the transport message was pre-determined by project requirements (HL7 v2 in G2GP and eDischarge; XML in ePrescribing), but within that the Toolkit places CDA documents, and attachments, in Managed Internet Mail Extension (MIME) Packages. Internal encryption of CDA documents can be requested by a vendor passing a common key.   The following data level validations have been applied, as they are implemented by the CDA Schema itself:- Codes cannot contain embedded spaces. These have been encountered in user-defined codes which, by their very definition, are not interoperable and an established best practice has been to place the related description in the Original Text element of the Concept Descriptor and omit the Code itself. Combined expressions of numeric test result values (e.g. a blood pressure reading of 120/80); these must be expressed as individual, numeric, results (i.e. systolic and diastolic blood pressures in this example).
• #7: Having outlined the challenges and applied solutions, it is now time to consider whether the interoperability and HL7 v3 CDA-specific issues have been overcome, and if so to what degree, by the methodologies applied. Ultimately, one can only speculate about the outcome of a relatively complex CDA implementation, in a multi-vendor, continuity of care project, such as GP2GP, without the use of a common data model. However, the author would consider the chances of success to be negligible. In fact, it is almost self-evident, that interoperability benefits from a shared, collaborative, rather than competitive approach; and the willingness of the vendors to participate and cooperate in this process, and adapt to its outcomes, was a feature that moved a member of the group to recommend this strategy to an Australian audience [13]. The overall feedback from the PMS vendors, suggests that the Toolkit has successfully abstracted, and separated, all of the CDA-related concerns from these projects. However, while it has facilitated the passing of data between disparate systems, the Toolkit cannot entirely mask the fact that semantic interoperability is extremely difficult to achieve unless all participating systems implement highly atomic data structures and common clinical coding systems. No data value supplied by a healthcare facility can be modified by the Toolkit – it can reject entries where mandatory items are missing (e.g. a Patient NHI or a Code without an accompanying Code System and Display Name) or invalidated by the CDA Schema (e.g. composite blood pressure result values), but it can never change one. The Toolkit has also provided a large amount of re-use, when extended to incorporate the additional CDA instances required by new projects. It has also been adapted by other organisations, in the NZ Health Sector, for use in new interoperability projects. Thus, the strategy of developing a shared component, to implement CDA-specific functionality, has allowed the lessons learnt in the early implementations to be accumulated, rather than re-visited. One area that might be improved is the increasing use of XML Schematron, rather than source code, to implement the rules outlined in CDA Implementation Guides and Templates. This additional separation of concerns might further the re-use of shared artefacts, particularly when the Toolkit is not used, and it is easier for vendors to deploy updates to individual XML files, rather than a new version of an application component. A paper on the use of Schematron, and CDA validation in general, has been published by the RIM Based Application Architecture (RIMBAA) Group [14]. In addition to the technical challenges, there is also a human element to interoperability projects and at this stage it should be noted that, although a ‘black box’ to implementing PMS software, the Toolkit has been developed using a ‘shared source’ approach with all relevant source code, unit tests and a sample test harness application being made available to each participating vendor. Consequently, the Toolkit was not developed in isolation and the lessons learnt were shared within the Sector. During the development stages of the relevant projects, numerous contributions were made by vendor representatives via project portals and at weekly teleconferences, occasional workshops and message exchange sessions plus individual visits. These were invaluable in resolving not only technical issues, but workflow problems such as how to identify the records of patients returning to a GP practice.
• #8: In this paper we have examined the challenges arising from the initial implementations of CDA in key New Zealand eHealth interoperability projects and the solutions designed to meet these challenges; namely the development of common data models and a shared software component, the NZ CDA Toolkit. Both solutions have proved successful on technical and practical levels with the delivery of the relevant projects, within relatively tight budgetary constraints, being at least partly attributable to the substantial reduction in duplication of resources resulting from the shared, co-operative, approach. Going forward, we are likely to see the adaptation of data models using the clinician-driven approach promoted by openEHR [15] Archetypes, as mandated by the Reference Architecture for Interoperability and the increasing development of CDA documents outside of the Toolkit, but facilitated by Template Libraries and Schematron that incorporate the lessons learnt from the development of the Toolkit. Basing the first national implementations of CDA in New Zealand on an open, shared and collaborative approach has established a significant framework for the comprehensive adoption of Clinical Document Architecture in the New Zealand Health IT Sector.