1. 1
NZ Primary Healthcare IT Integration -
May 2014
Implementation Showcase
Peter Jordan
Solution Architect
Patients First
2. Who Are Those Guys?
www.patientsfirst.org.nz
Patients First is the NZ Primary Healthcare IT Group: one of six core bodies delivering
the National Health IT Plan – by enabling effective integration and measures that matter.
3. National Solutions
GP2GP version 1 (90% adoption)
NZ ePrescribing Service – 2 million scripts
HIE Test Platform… http://itp.patientsfirst.org.nz
o PMS Review – Round 2
o GP2GP version 2.1 – Max Message 20Mb
o E-Enrolment – Phase 1 Design
o Integration PlatFORM
“Interoperability is not a boat race. One team can’t win by
rowing better than another. We are all rowing the same boat.”
…on the slow boat to healthcare IT integration…
5. Foundations…
HISO 10040 Health Information Exchange
10040.3
Documents
CDA
10040.2
CCR
SNOMED CT
Archetypes
10040.1
R-CDRs
XDS
• Challenges - encountered in early CDA implementations
• Solutions – common Data Models & NZ CDA Toolkit
• Lessons - learnt in the process
7. Project Solutions
• Implementation Types
• GP2GP – Continuity of Care
• E-Discharge Summaries – Connected Care
• Community E-Prescribing – Order Filling Service
• Shared Components
• Common Data Model – Semantic Integration
• Client Software Adapter – NZ CDA Toolkit
8. Shared Data Model
C1: Bridge the logical data model in Business Requirements and
the vendor’s physical data models - via the CCR/CCD standard
(Sections/Entries). Highest or lowest common denominator?
“Don’t exclude anything that any one of us has.”
• Mandatory Sections – none in GP2GP
• Required Elements – only patient & record identifiers
• Extensible – Name-Value Pairs
• Linking Entries – to Encounters
• External Documents – linked to any Entry
• Project variances – e-Prescribing ordering elements
9. NZ CDA Toolkit
Client-side adapter; a class library facilitating the creation,
validation, packing and consumption of CDAs.
• C2: Data Typing – translates Data Model to CDA
– Which Act class – act or observation?
– Constants for identifiers e.g. 2.16.840.1.113883.6.96 = SNOMED
– Single NULL
• C3: Validation
– Encapsulates Schema (structure), adds business level (content)
– Removes some pain points (UCUM) – but not all (Schema mandates)
• C4: NZ-Specific Requirements – Additional Demographics
• C5: Presentation – GP2GP version of standard CDA Style Sheet
• C6: Transport Packaging – Project-specific
– GP2GP & e-Discharge: MIME package within HL7 v2.4 message
– E-Prescribing: CDATA section in NZePS XML message
10. Gp2Gp Review
Have the challenges been overcome?
• Data Model – Would GP2GP be possible without one?
– Vendor willingness to co-operate
– Business Requirements imprecise; Implementation Guide, highly complex
• Toolkit Development – Common ownership:
– Shared Source and Test Harness application
– Co-operative development; teleconferences, workshops
• Reusability – Accumulate lessons learnt, not revisit
• Validation – More granularity via XML Schematron
• GP2GP Review – Vendor Issues in 1st
Year
– Validation (legacy data)
– User-Defined Codes containing spaces
– Large message files (> 5Mb)
11. NZ ePrescription Service
•Scope – Nationwide community e-prescribing
•Solution Design - Based on one Australian implementation
•Endpoints - 4 GP PMS and 2 Pharmacy Vendors
•Hosting - NZ Connected Health Network
•Exchange - Vendor HIE Registry and Broker
•Adapter - Client or Cloud Hosted options
•Prescription - CDA document for each medication (item)
•Messaging - Proprietary XML for metadata
•Shared Component - NZ CDA Toolkit
•Medication Standards - NZULM and NZ Formulary
14. New Zealand Solution
• Maturing CDA Landscape
• NZ CDA Toolkit – Specifications, but not standards
• HISO Standards – Simplified CDA Templates
• Vendor Products – Native CDA Capability
• Integration as a Service
• Certification and Integration – NHITB Strategy
• Integration Test Platform – Web Site & Web Service
16. Integration Test Platform
• ITP Services
• Validation Tool – tests messages & documents
• Downloads – sample test instances
• Reporting – test results by application & version
• ITP Interfaces
• Web Site – additional rendering examples & links
• Web Service – RESTful business functionality
• ITP Validation Levels
• Message Transport – CDA document wrappers
• Document Formatting – Structural & Document Template
• Data Content – Header, Section, Entry & Item Templates
17.
18.
19. Testing Discussion
Will the Integration as a Service approach succeed?
• Feedback – Generally positive
– PMS vendors (GP2GP v2) & DHB CIOs
• Operational Principles – Broad consensus:
– HISO as certifying authority, Patients First the endorsed test agency
– ITP as enabler, rather than enforcer, of standards – educative feedback
• Usage – UAT moving into production for InterRAI & GP2GP v2
• HISO Standards – Simplified CDA Templates
– Hierarchical Descriptions - (c/f XML Schematron –arcane conformance statements)
– Human-understandable error and warning messages
– Richer validation provided by OO languages
• Service-Oriented – Web Form and RESTful interfaces
– Centrally hosted and targeted testing – persists beyond project lives
– No silo-based testing of entire product suite deployments
20. eEnrolment Principles
• A single electronic process for enrolment and registration
• Standardised on a national basis
• Generic forms web-based solution
• Integrate with PMS
• Reduce burden at practice level
• Improve data quality
• Remove 3 month stand down period for patients
• Reduce risks
21. Integration PlatFORM
• Consistency of interface
• Certainty of integration
• Pay for one build cost
• Pay for one maintenance cost annually for integration
• Reduce time to integrate
• Reduce complexity
• Guarantee information consistency between systems
• Web based forms access and development integrated with
PMS forms with reach to all GP desktops
• Point to point messaging alternative – RESTful Web Services
Editor's Notes
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.
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.
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.
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”)
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).
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.
Testing is a well established and critical process in the software development lifecycle with several clearly defined phases one of which is defined as integration testing – the stage at which individual software components are combined and tested as a group [9]. In the context of health informatics projects involving the exchange of data between systems, this also includes validating that data sent by one system can be successfully read and imported by another with no loss of semantics – interoperability testing. More often than not, this will involve components produced by different organisations – and an element of collaboration between the parties. In the sagacious words of the Gartner Group’s Wes Rishel…”interoperability is not a boat race. One team can’t win by rowing better than another. We are all rowing the same boat.” [10]
Testing the exchange of CDA documents is greatly aided by the fact that CDA is an international standard – based on the HL7 Version 3 (v3) data types and Reference Information Model (RIM) – for the production of all clinical documents. However, this global use also necessitates a highly flexible design and, as such, one that is open to diverse interpretations and implementation standards – hence the need for national and project-based constraints and stringent compliance regimes.
CDA Document Validation
CDA uses the industry standard XML format and consequently is able to take advantage of some well-established file based validation technologies. Nonetheless, these have some severe limitations, for example XML Schema (XSD) provides structural checking, but offers only limited content validation. While incorporation of these checks into individual, endpoint systems, is a relatively trivial task – they provide very little guidance for end-users in terms of error diagnosis
Content Checking via Templates and Schematron
Document content validation is commonly based on Implementation Guides 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 Implementation Guide and Template rules using XML Schematron [11] and/or custom-built software components. Traditional’ CDA Templates consist of a series of individual conformance statements incorporating both the computable expression of the rule and the error message to be presented in the event of non compliance.
Client-based Test Harness Applications
One strategy for employing integration testing is the creation and deployment of client-based Test Harnesses, typically Windows Forms applications, to all project participants. This has been employed, with a high degree of success, in the projects that have utilised the NZ CDA Toolkit – albeit from the advantage point that the concerns of generating and consuming the relevant documents and transport messages were abstracted away from the primary care Practice Management Systems (PMS) by the Toolkit. In this situation, the principal functions of the Test Harness were to supply full end-to-end working examples for the users, with the focus on population of the common data model and document rendering options. It was also part of the shared-source methodology employed in the development of the Toolkit itself – including the validation routines.
Generic CDA client validation tools, notably the open source Eclipse Instance Editor [12] are also freely available, and can incorporate project specific templates and schematron. However, while they are valuable aids to CDA education and development, they are not really designed for dedicated integration testing
In general, this approach has some obvious limitations in interoperability project testing – even if a library of sample documents produced by each participant is made available from an on-line project management site. One such restriction being that it provides no means by which organisations can demonstrate project compliance without supplying test versions of all their systems to a centralised project testing capability – a potentially lengthy and costly process, particularly where there are complex installation and update routines and multiple versions to contend with. The other limitation of a project based approach is the limited shelf life of the project and the persistence of testing artefacts once the project has been completed.
The Overseas Picture - On-Line Test Platforms
Internationally, we have seen the development of Web-based Test Platforms of varying scope and jurisdiction. Some have been developed by those closely associated with the standards development organisations themselves – e.g. The Lantana Consulting Group’s CDA Validator [13], others by national standards organisations or testing laboratories – e.g. The Australian Healthcare Messaging Laboratory [14]. Large-scale national eHealth projects have also spawned integration testing platforms – notably the National Institute of Standards and Technology (NIST) [15] tools that support the Meaningful Use programme in the United States. In Canada, the private sector has produced an e-Health testing platform - Test Level Seven from Intelliware[16] - to support both the generic national standards defined by Canadian Health Infoway, and province-specific processing and business rules.
The New Zealand Solution – Integration as a Service
It was clear from the outset that the Test Harness supplied to compliment the use of the NZ CDA Toolkit was a short-term measure designed to support individual project specifications rather than nationally-endorsed standards. Once CDA capability became native to products and applications, and HISO had developed CDA template standards, a broader and more independent approach was required. This was also informed by some of the lessons learned in nearly twenty years of HL7 version 2 messaging where integration testing was often performed as a function of the transport message service provider, with varying degrees of success.
Certification and Integration
In 2010 the National Health IT Board commissioned Patients First to undertake work in the area of evaluating a primary care PMS certification regime. This included a desk based review of international examples and review of current standards in the New Zealand context that would lend themselves to such a regime [18] What became apparent in the review of international examples where certification is a part of the landscape is the common denominator there is a (high) degree of federal funding either directly to vendors or a subsidy to healthcare providers for adoption of certified products. In many cases these countries are seeking to increase adoption of systems in primary care and environments beyond hospitals. Examples where this is the case include The Netherlands, UK, Australia, Denmark and the US.
As evidenced in the Commonwealth fund literature [19] New Zealand already enjoys one of the highest rates of system adoption in the world. New Zealand does not have the national “levers” of incentive payments and subsidies of other countries with a certification regime in place. New Zealand has to look at other options to achieve the same goal.
The approach that has been adopted in New Zealand is a phased approach. Currently there is an independently facilitated Expert Group of clinicians and technologists who review PMS systems against a set of 4-5 criteria each year. The list of focus areas changes each review (i.e. is added to) with the opportunity to re-assess earlier review areas for vendors if the vendor indicates that there has been material changes to their systems in the areas previously reviewed. This review uses available standards (professional standards and technology standards where available and relevant in the New Zealand context) and is largely a subjective review by the panel against these criteria. A document of questions is published as an RFI to the vendors who are invited to respond and the expert group uses this feedback supplemented by their own working knowledge of the various products to review and rate the products against the criteria. A review was published in 2012 [20] and another underway in 2013.
This approach is regarded as an interim step toward a more structured and standards based certification regime that the National Health IT Board has indicated they wish to put in place for the eMR (electronic medical record) environment in New Zealand (i.e. broader than the current primary care PMS focus). It is envisaged that the current ratio of subjective (expert) analysis and objective standards based analysis of vendor products under the current regime (approximately 75/25 ratio) will shift with the use of tools like the Integration as a Service test platform and inclusion of new and updated standards into the test harness to a 75% “standards based testing” against the test platform and a 25% subjective commentary/assessment on usability.
The Integration as a Service test platform plays a fundamental role in the “machinery” of achieving this goal.
The goal for the sector is a “plug and play” environment whereby end users and purchasers of systems can be confident in the knowledge that their choice of systems will integrate with the broader eco-system if they see proof of certification against standards. The initial focus of the standards in the test platform is on those that contribute to interoperability between systems and settings of care.
The Integration Test Platform
The method chosen to enable New Zealand HIE participants to test and demonstrate compliance with CDA standards is the Integration Test Platform (ITP). The ITP achieves this objective by providing the following services to registered and authenticated users:-
A Validation Tool that allows users to pass individual test messages and documents (‘test instances’) and receive instant feedback in the form of a structured compliance report.
Downloading of sample, test messages and documents for users to demonstrate importing and rendering in an eHealth application.
Document links to the relevant standards and specifications for users to reference.
Sample outputs in the form of the human-readable text sections of CDA documents – using a standard stylesheet.
Users can interact with these services in one of two ways:-
A Web Site, containing pages for registration, logging on, validation, downloading, rendered examples and links to the related standards and organisations.
A RESTful [21] Web Service that provides all the business functionality behind the Web Site.
As with most of the overseas services, the ITP matches and augments the functionality of an application testing harness, allowing users to test individual files, rather than being a vendor to vendor “connectathon”. However, in many cases (for example GP2GP record transfers) it is envisaged that users will be able to perform end-to-end interoperability demonstrations by showing data displayed in their systems, before it is packaged into the relevant test instance, sent to and validated by the ITP and then consumed and re-displayed by the same application. In other scenarios, it may only be appropriate for a particular eHealth application to consume a test instance (e.g. a primary care system handling an eDischarge Summary from a hospital or an interRAI document), or to generate one (e.g. a GP system creating an eReferral to a specialist provider).
The Validation Tool requires a registered user to select the relevant standard, upload a document or containing transport message file to test against that standard, and provide the name and version number of the software application which was used to generate this test instance. The testing and reporting is performed at three separate levels:-
Message transport – CDA is a document standard, so it has to be transported within a message file. The ITP tests that this message file is of the type mandated by the relevant standard or specification. For example CDA documents containing GP2GP transfers must be transported in an HL7 version 2.4 message file.
Document formatting – this checks that a document meets the basic requirements of the CDA schema, i.e. structure validation. It also validates the top level, document type template, identifier against that required by the selected specification. Should, for example, the Discharge Summary Template Identifier be found in a document sent for testing against an InterRAI Assessment standard, a formatting error will be reported and the validation process will not proceed to the next level.
Data Content – starting with the CDA header, and then moving on to each individual section, data validation takes place as the final stage. Initially the existence of each mandated template identifier is checked and the existence of any unexpected identifiers reported. This leads to an increasingly granular check on the individual data items themselves; the absence of any item that is mandated by a standard (e.g. a drug code in an entry to a list of medicines) or the non-standard representation of a data item (e.g. the use an incorrect code or coding system).
All validation test results (but not test instances) are stored in a relational database and users can request reports of these results by application and version number to submit as evidence to the certification programme. The NZ CDA Toolkit is utilised in the validation engine’s business layer; partly to enable the initial scope of the service to include existing CDA-related specifications, such as GP2GP, but also because source code is considered to be the most efficient and flexible method of implementing the new HISO CDA template standards. This assertion will be further explained in the following Discussion Section.
At this stage it should also be noted that users are strictly advised not to send any ‘live’ patient data to the Test Platform or data containing details that could identify any existing patients – in particular test National Health Index (NHI) numbers, names and dates of birth must be used in all submitted test instances. In cases where the encryption of clinical data is required, the Test Platform cannot decrypt any data encrypted with keys used in production systems, it only contains test keys.
Having outlined the requirements for standards compliance testing and the solution applied, it is now time to consider to what extent the Integration Test Platform can be expected to meet those challenges – at the various operational and technical levels.
The overall feedback from the PMS vendors, some who will be using the ITP for the first time in the testing stage for version 2 of the GP2GP patient record transfer system, has been very positive. Canvassing of this topic with District Health Board CIOs has also met with positive feedback as the integrated nature of care delivery is demanding increased integration between disparate systems across various settings of care.
There appears to be a broad consensus for the operational principles – HISO as the certifying authority, Patients First (the ITP developers) as an endorsed test agency and the platform itself as an enabler, rather than an enforcer, of standards. The Test Platform can translate standards into tested CDA documents and provide a feedback mechanism to HISO on possible omissions and the ability of endpoint systems to implement standards in practice. As such it can also perform an educative role for the market.
In many ways, the ITP is still at the user acceptance testing stage. Usage so far has been restricted to existing projects – such as the NZ ePrescribing Service – where the NZ CDA Toolkit is still used. However it has been developed concurrently with the new HISO CDA Template and InterRAI CDA standards and there has been a significant level of collaboration between the relevant project teams. The implementation of validation for the 3 InterRAI Assessment Types is particularly significant as these documents are all produced directly by a vendor system, without the Toolkit.
The notation style expressed by these new HISO standards reflects a significant change in direction from CDA Templates expressed by means of copious, and rather arcane, conformance statements to Hierarchical Descriptors (HD) – a concise, almost shorthand, representation of rules for determining the contents of clinical documents. The language of the traditional conformance statements is constrained by the need to convert them into computable artefacts – Schematron files containing XML expressions. In contrast, the (shared) source code approach enables the use of error and warning messages tailored to their target audience – the human end user community. It is also a strongly-held view of the authors that fully-featured, object-oriented programming languages provide a far richer validation tool than those provided by the extensions of XML, predominantly a mark-up language. For example, languages such as Java and C# make it is far easier to implement multi-dependency rules over the entire scope of a document, identify missing or extraneous data and to link seamlessly with on-line validation resources, such as terminology services.
The provision of an on-line test platform, with both Web Form and RESTful interfaces, is also considered to be concomitant with the general trends in the IT industry towards service-oriented architecture and ‘cloud’ services’. Such architectures satisfy the stated wishes of vendors to remove dependencies on software components hosted at individual facilities and the related deployment issues. Furthermore, much frustration has been expressed about the silo-based testing methodologies employed in some eHealth projects that dictate the installation of entire product suites on test servers and workstations.
