Dissecting the Reference Architecture for Interoperability

Editor's Notes

• #3: (The Anatomy Lesson – Rembrandt, 1632)
• #4: These are the three building blocks – or pillars – of the HISO 10040 series that embodies the central ideas of the Reference Architecture for Interoperability10040.1 is about regional CDRs and transport10040.2 is about a content model for information exchange, shaped by the generic information model provided by CCR, with SNOMED as the default terminology, and openEHR archetypes as the chief means of representation10040.3 is about CDA structured documents as the common currency of exchange – not every single transaction type, but the patient information-laden ones
• #8: The diagram shows the CDA solar system, with the blue planets representing sets of templates and document types we use locally, deriving from international specifications (green)We are strongly internationally influenced, reusing wherever the fit to requirements is better than we could hope to achieve by ourselvesThe Continuity of Care Record (CCR) – although not itself CDA – is the origin of our conceptual data model for information exchangeThe other document types shown are: Consolidated CDA (CCDA) developed by the US’s ONC for Health IT; Continuity of Care Document (CCD); local GP2GP; local e-discharge summary (eDS); local e-prescription document; local transfer of care – generic referral/discharge document
• #9: The work on transfer of care is essentially an extension of the Reference Architecture for Interoperability, applying those same patterns
• #10: Architectural requirements for e-referral, discharge and shared care solutionsThe diagram shows a continuum of care enabled by e-referral and discharge applications that are repository-centred and document-orientedThis is where we end up if we apply our general rules for interoperability to the particular domain of transfer of careThe reference architecture is out for review by the vendor community – comments due 30 June
• #11: What standards do we need to reach the 2014 goal?Of these, HISO 10040 is an interim standard (awaiting trial implementation)Transfer of Care Standard is scheduled to be released for public comment in August 2012, ePharms (necessary for the NZePS) after thatThe Comprehensive Care Assessment Document will be a standardised interRAI extractWe will also have refreshed health identity standardsWe might also standardise on a framework for RESTful APIs in the health.nz namespace, and an XSLT CDA rendering stylesheet
• #12: This is how the Ministry’s e-health programme sees the sector’s information landscapeThere is certain core health information, held nationally for every person – this naturally centres on the NHI as the master for patient demographic informationWhere individuals have special needs, they might have a care plan with input from a multi-disciplinary care team – the sector is working on maternity shared care, Well Child (Plunket etc), and long term conditions shared care records, as prioritiesR-CDRs store objective clinical records such as test results, transfer of care documents, and perhaps also medications listsThese information resources are available to the many types of system used at point-of-service
• #13: This diagram shows a virtual shared care record as the sum of many parts stored in different locations, e.g. core health information in one repository, lab results in another, the care plan in anotherIndex entries point to individual repository-held components of the shared care recordDocuments can be stored and retrieved in their native form, or stored in some decomposed form, and materialised on demandBoth collections of records and individual components can be registered – e.g. a set of results versus one result in particular
• #14: The first of three examples of the emerging class of interoperable shared care solutionsComprehensive care assessments with the sector’s interRAIapplication, hosted nationallyAssessments are created and stored in one system, but used in others – for care planning, by the GP, on admission to hospitalDeveloping this capability is an incremental taskCurrently, the application can present PDF-formatted assessment reports within an application sessionBuilding on this, CDA level 1 can be used to attach metadata to the report and it can be conveyed via web services to portal usersFinally, when an XDS infrastructure is in place, and we have a suitable set of templates, we can move to CDA level 3 content shared out of an XDS-enabled repository
• #15: This is one of the frontiers – the use of a repository-held managed medications list as a component of a shared care recordThe care team – GP, specialist, pharmacist etc – exercises stewardship over the managed list, updating it at contact with the patient, such as when a new medicine is prescribed or a dose alteredThe managed list can be pulled down to point-of-care systems, updated, and posted backShould we have a standard stylesheet for rendering CDA documents?
• #16: This is another frontier – this is not where we put our heads down and ignore what’s happening; quite the reverse, this is where we should be implementing changeThis initiative enables pharmacies to play a bigger part in helping selected patients with multiple long term conditions to manage their medicationsThe initial scope will include NHI integration for demographics and enrolment; beyond that we have NZePS; and then interfaces to comprehensive care assessment, referrals and My List of Medicines
• #17: Solution scope options for NHITB/healthAlliance pioneering work on R-CDRsAn important use case is shared care system access to repository-held records, such as test results, discharge summaries and My List of MedicinesThere is also the ‘after hours’ use caseThere is an interesting comparison with the implementation of Australia’s PCEHR, which has the following features:Single national XDS registry (XCA not required)Registry and repositories implement XDS and ATNAPatient privacy consents (non BPPC) based on Practitioner-Role-Organisation and Organisation-Patient-Document relationships (with opt-outs)Eight CDA document types in circulation – a mix of levels 1, 2 and 3Registry vendor supportive of PIXV3 (though not implemented)
• #18: As part of the trial implementation or otherwise, what do implementers need to consider in architecting interoperable solutions?DHB regional organisations should each be implementing an XDS-enabled R-CDR, comprising an XDS registry and XDS-enabled component repositoriesThey should also plan to implement XCA gateways, in order to exchange data inter-regionally Nationally, there will be a similar ‘info-structure’, this one providing an XDS interface to ‘core health information’ (enrolments, allergies and alerts, immunisations), comprehensive care assessments, and nationally held specialty informationTest results should be copied into the R-CDR and registered at suitable levels of granularity for retrievalIntegrated family health centres (IFHCs) keeping appointment and encounter records, and care plans will tend to use ‘local’ systems, but these should be designed to register content with the R-CDR (or, at least, expose an XDS registry-repository interface of their own)XDS-enabled R-CDRs make life simpler for hospital/community portal products, which can then populate their results trees from (in theory) one sourcePMS products and the new breed of shared care systems should be architected as consumers (and not necessarily producers) of web services, able to share regionally-held data resources
• #20: The Transfer of Care Reference Architecture introduces two important CDA document types – a generic e-referral/discharge document and a ‘health status summary’, which is used for general purposes in shared care, such as pre-populating forms and shared care recordsReferral and discharge documents are shared out of an XDS-enabled regional document repository, which is integrated with the referral management systemXDS-enabled referral and discharge web services are available to all point-of-service systems (which don’t themselves need to implement XDS actors)The top of the diagram extends to a transfer of care data mart in the regional data warehouse
• #21: The components we require at the PMS or, more generally, point-of-service system interfaceThe key concept is that this is a ‘right side up’, client-server architecture, with the PMS as a consumer of web services, in a one-way client-server relationship with regional and inter-regional web servicesThis is contrasted with the Online Forms architecture, which is a little unusual in that the relationship is turned around the other way, such that the behaviour of the PMS is directed from outsideThe diagram shows the CDA toolkit (introduced as part of the GP2GP solution) as a separate component, but this is essentially embedded functionality within the PMS, which will also have HTTP client capability
• #22: This diagram illustrates a suggested pattern of RESTful interactions between a PMS and referral web servicesEnd-to-end, this is a matter of launching and filling out a referral form, and submitting it to a shared repository
• #23: This diagram shows an information cycle from use of a locally generated health status summary document to populate a referral form, which in turn populates a referral document for deliveryDocuments are fully structured, with display elements deriving from coded elements