Computer Standards & Interfaces 35 (2013) 313–328
Contents lists available at SciVerse ScienceDirect
Computer Standards & Interfaces journal homepage: www.elsevier.com/locate/csi
Specifying and building interoperable eHealth systems: ODP benefits and lessons learned Andy Bond, Andrew Hacking, Zoran Milosevic ⁎, Andrew Zander National E-Health Transition Authority. Level 2, 10 Browning St West End, QLD, 4001, Australia
a r t i c l e
i n f o
Available online 5 January 2012 Keywords: eHealth e-Health RM-ODP Interoperability Framework
a b s t r a c t This paper describes the experiences of Australia’s National E-Health Transition Authority in using the RMODP to address a number of interoperability challenges in Australian eHealth. The RM-ODP viewpoints provide the separation of concerns across a specification, allowing direct support of independent capability levels within an eHealth community. The RM-ODP provides precise architectural expression, including that of business and policy contexts critical for eHealth. This precision is important for a tools-based architectural approach that supports traceability between requirements, design and implementation. The paper identifies some issues encountered while using the RM-ODP, which provide input into further standardisation efforts. © 2011 Elsevier B.V. All rights reserved.
1. Introduction eHealth describes the combined use of electronic communication and information technology to support the clinical, educational and administrative practices of healthcare. As a community of practice, healthcare encompasses a variety of delivery modes and environments and the intersection with information technology is therefore broad. In major metropolitan clinical settings, eHealth will support modern ICT practices and dedicated support infrastructures, while in smaller regional settings, healthcare services may have little to no ICT support. The Australian sector spans both public and private sector providers who often operate under similar, but different, policy contexts and business goals. One opportunity that binds all of healthcare is the emerging availability to both patient and clinician of healthcare information, either exposed through various web sites or directly between clinicians. This potential knowledge base, developed through the sharing of clinical data, has been said to provide the potential for greater clinical benefit than any new drug [16]. However, unlike the drug development lifecycle, knowledge is created, managed and shared with little underlying rigour, which means that the efficacy, accuracy and completeness of the accumulated information set is often unknown. To enable greater trust and connectedness of information, there is a need both to increase the information management capabilities in which the information is created or harvested, as well as to negotiate information-sharing relationships that support the traceable provenance and trust relationships between consenting parties. Clinicians, patients and other parties all have a role to play in contributing to and
⁎ Corresponding author. E-mail address:
[email protected] (Z. Milosevic). 0920-5489/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2011.12.005
using this information environment for greater community health benefit. In light of the varying ICT capability and maturity across the sector, this complex environment requires support for both the co-existence of heterogeneous solution approaches, as well as clear transition strategies relative to different segments of the healthcare sector. Interoperability is a key business building block as different parts of the sector link together to coordinate information flows. No single architecture will meet the requirements of the whole sector, but rather a strategy is required that allows individual architectures to emerge and multilateral interactions to be enabled, while adhering to a layered set of interoperability and architecture obligations. Such a strategy should lead to sustainable interoperability outcomes including development and adoption of national and international standards. Within Australia, eHealth is further complicated due to its federated political and legal system. In order to deal with the above challenges, the National eHealth Transition Authority (NEHTA) was established to lead the progression of eHealth in Australia, with a goal of creating a sustainable and interoperable eHealth environment. NEHTA is also a national eHealth specification organisation closely linked with the Standards bodies in Australia and internationally. Further, it is a national implementation organisation facilitating delivery of national eHealth infrastructure and lead implementation solutions. As a reflection of NEHTA's multiple roles above, its approach to interoperability, both at the broader eHealth architecture level and at the specific eHealth solutions level, is to support the architecture landscape structured into the following areas: • Interoperability Framework, which provides a common set of interoperability concepts, patterns and structuring rules to support the coexistence and instantiations of different solution frameworks which reflect specific architecture choices of eHealth organisations wishing
314
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
to participate in an eHealth ecosystem. The Interoperability Framework is based on ISO/IEC RM-ODP [1–4] and described in Section 3. • Solution frameworks, which provide a further level of architecture expression to the concepts identified in the Interoperability Framework. Each framework reflects the organisation's own architecture design, modelling and methodology choices. NEHTA has established its own solution framework, using and extending the concepts from the Interoperability Framework and representing them using UML [18], as will be shown in case of two solution specifications presented in Sections 4 and 5. • Solution specifications, developed using a particular solution framework. Use of a single solution framework by an organisation and its community facilitates consistency of the solution specifications, allowing the products that are based on them to better interoperate. Examples of solution specifications developed by NEHTA are Electronic Transfer of Prescription (ETP) in Section 4 and the National eHealth Authentication Service (NASH) in Section 5. The above approach of supporting progressive level of architecture expression reflects the balance of requirements for long-term nationally sustainable architecture approaches and the need for pragmatic individual solutions, both produced by NEHTA and other eHealth organisations. In particular, the approach promotes the use of logical specifications while supporting multiple implementable technologies either at one point in time or over time. It also allows implementers to develop their product and service specifications with the rigour required of national specifications, which in turn is augmented by a sound conformity assurance framework (the initial approach of which was also presented in the Interoperability Framework). Many of the challenges above can be addressed by applying the RM-ODP standards and this paper discusses NEHTA's experiences in the use of RM-ODP gained over a period of five years. During this time, NEHTA: • published two versions of the eHealth Interoperability Framework specifications [5] • used this framework as an architecture foundation for developing several eHealth specifications, such as Secure Message Delivery, Electronic Transfer of Prescription and National eHealth Authentication Service [6] • established a separate initiative with a focus on Conformance, Compliance and Accreditation [6] • contributed towards the development of the architecture underpinning the HL7 standards, in the form of the HL7 Service Aware Interoperability Framework (SAIF) [7]. The paper will also highlight areas where we (the authors) experienced difficulty in applying ODP when designing specific eHealth applications based on the principles and concepts described in the Interoperability Framework. While some of the difficulties arise from the relatively low maturity of software tools to support the RM-ODP modelling, other difficulties reflect certain areas where we needed a more expressive set of concepts and mapping into the UML modelling environment. These are areas where NEHTA can potentially provide input into further standardisation of RM-ODP and related eHealth standards. 2. Use of ODP standards The ODP standards provide a sound foundation for the delivery of consistent NEHTA products, ranging from the NEHTA solution specifications to the establishment of the national conformity assessment scheme. The following is a list of key approaches that were adopted from ODP standards.
2.1. Separation of concerns — use of ODP viewpoints The cross-organisational and cross-jurisdictional nature of eHealth in Australia involves many different stakeholders with different concerns and different levels of maturity. To deal with the complexity of such a system, the NEHTA Interoperability Framework has adopted architectural recommendations from ODP standards, according to which a complex system is best viewed from various viewpoints, to reflect concerns of different stakeholders [1,2]. The ODP enterprise viewpoint has been adopted through the use of a majority of the modelling concepts. The NEHTA Interoperability Framework refers to this abstraction as the organisational interoperability perspective. The ODP information viewpoint has been adopted through the use of a small set of information modelling concepts, and in the NEHTA Interoperability Framework this is referred to as the information interoperability perspective. The third interoperability perspective, the technical perspective, is mostly based on the ODP computational viewpoint, while the ODP engineering viewpoint was of less relevance at the time, but is likely to be used in future to address requirements for specific middleware solutions or engineering mechanisms and functions. Similarly, the ODP technology viewpoint is of more relevance when describing implementation choices and therefore for specifying testing requirements. Indeed, these viewpoints will be used in the context of specific solution architecture and product specifications, such as Secure Message Delivery, Electronic Transfer of Prescriptions, and Personally Controlled Electronic Health Record and they are also supported by the HL7 SAIF standards. 2.2. Precision of expression — use of ODP modelling languages One of the distinguishing features of ODP standards is the precision of the modelling concepts adopted within this standard. The precision is a result of many years of ODP development by leading experts in open distributed systems development, both from academia and industry, and from a wide range of industry sectors, including government, telecommunications and finance. This precision is highly important when considering the key role that software tools play in ensuring traceability from requirements via specification to implementation, as well as in the context of conformity assessment processes. Section 3 highlights the key modelling concepts adopted by the NEHTA Interoperability Framework, structured according to the three interoperability perspectives. These concepts provide the foundation for consistent NEHTA specifications for eHealth infrastructure and solution components [6]. 2.3. Conformance and compliance framework ODP provides a rigorous framework for supporting conformance and compliance requirements and NEHTA has found this a valuable approach for addressing the specifics of its role in the Australian national eHealth outcomes. On the one hand, NEHTA is involved in developing new eHealth specifications and many of these specifications will need to rely on the use of existing standards, ranging from infrastructure standards such as protocols, security standards and specific component standards (directories), to clinical and policy standards. The ODP concept of compliance is a useful mechanism for guiding the architects and designers in making sure that the new specifications are consistent with existing de-jure and de-facto standards as well as policy frameworks. This consistency is currently achieved through the review of new specifications against the standards that these specifications use. On the other hand, NEHTA eHealth specifications provide new components of national functionality for specific eHealth infrastructure solutions and eHealth applications, and these specifications will be supported by many vendors with different implementation
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
approaches and technologies. In order to support interoperability of different vendors' offerings, there needs to be a way of providing assurance that these products satisfy the specifications. This is where the ODP concept of conformance is used, which relates an implementation to a specification. This concept is based on standard approaches for testing within the ISO conformance assurance community and NEHTA eHealth specifications now include a well-defined set of conformance points. The approach for specifying conformance points is defined in the ODP standard and NEHTA has adopted this approach to assist vendors and third-party testing organisations as a guide for new product developments as well as to support testing activities. It is worth noting that NEHTA's approach to conformance and compliance, which was first published in the NEHTA Interoperability Framework, has also influenced the international eHealth standardisation community, in particular as part of the HL7 SAIF's Enterprise Conformance and Compliance Framework (ECCF). 2.4. UML for ODP profile The adoption of ODP standards for the expression of architecture concepts and artefacts as part of NEHTA specifications has provided a good base for defining precise semantics of the eHealth specifications from business, information and technical perspectives. However, the full benefits of this approach are gained when these concepts are considered in the context of software tools to support a computable expression of eHealth architectures. The ISO standard, UML4ODP [4], provides this added benefit as it allows the use of a wide range of UML-based tools to support the establishment of traceability from requirements to specification, as well as traceability between different models. The use of such tools provides significant cost savings and quality improvement because changes in the requirements and models can be propagated to the dependent models, including the generation of new documents based on the models. We envisage that the future use of software tools that support model-driven engineering can add further benefit, for example, allowing support for transformation between different models. This could include transformation between models that support different eHealth systems, for example between different versions of HL7 Version 2 messages or between HL7 Version 3 based CDA (Clinical Document Architecture) [17] and HL7 Version 2 message formats. 3. NEHTA Interoperability Framework The NEHTA Interoperability Framework provides a key set of architecture abstractions and guidelines for capturing requirements, designing and building eHealth specifications. The Interoperability Framework is structured in terms of the following components: • Interoperability languages provide a set of modelling languages developed for different groups of stakeholders. These languages essentially form architecture description languages that can be used to underpin any architecture framework that claims compliance with the Interoperability Framework, or derived solution frameworks or enterprise architecture frameworks. • An interoperability assurance framework contains a set of guidelines to support compliance and conformance testing, through identifying specification, conformance, compliance and accreditation communities, each with a clearly defined set of roles. Many teams in NEHTA now apply compliance criteria when developing their own specifications, and express their specifications using conformance points, as outlined in Section 2.3. A separate team was also established with the main focus on supporting the definition of processes, templates and tools to guide both NEHTA teams and implementers in developing quality testing procedures and downstream certifications. Further information can be found at [5] and [6].
315
• Interoperability guidelines define a set of interoperability principles and patterns to guide interoperability solutions, as well as an Interoperability Maturity Model, which is developed specifically to support eHealth organisations establish systematic interoperability capability improvement programs. An interoperability framework is closest to the systems of systems concept used in a number of US government frameworks, in particular in the Department of Defense Architecture Framework (DoDAF) [9] and the Federal Enterprise Architecture Framework (FEAF) [10], and to the interoperability frameworks proposed by the Australian Government Information Management Office (AGIMO) [8]. Note that the NEHTA Interoperability Framework also positions various enterprise architecture frameworks with respect to the NEHTA Interoperability Framework [5]. The main purpose of these frameworks is different from that of an interoperability framework. The focus of enterprise architecture frameworks is on ensuring that the internal IT resources and the applications in the jurisdictions are aligned with and optimally used within jurisdictional boundaries, in order to operate effectively and efficiently. In some larger jurisdictions, the emphasis is also on ensuring interoperability between their own systems, as well as interoperability with organisations outside of the jurisdiction. In this context, the national architecture components and infrastructure delivered by NEHTA provide important points of integration and interoperability, which are beyond the boundaries of any one enterprise or jurisdiction. Note that NEHTA itself makes use of the TOGAF framework [11] to support its own architecture development processes. The RM-ODP has been extensively used to provide the relevant concepts of the interoperability languages as well as to structure the interoperability assurance framework. The NEHTA Interoperability Framework currently includes three sets of languages, reflecting the needs of different groups of stakeholders, namely organisational, information and technical languages described in Sections 3.1, 3.2 and 3.3. It is worth noting that the current version of the Interoperability Framework recognises the need to clearly define correspondences between different interoperability perspectives according to the ODP correspondence framework and it is anticipated that this will also be addressed in future versions. 3.1. Organisational interoperability The ODP Enterprise Language concepts and structuring rules [3], especially the community modelling concept, provided a precise and flexible framework for describing the combination of the organisational context and the positioning of IT systems in the delivery of eHealth services. Community is used as an overarching concept for the definition of organisational roles, processes and policies in an eHealth system – providing statements of expected behaviour for enterprise objects' participation in a community. This expected behaviour is stated in terms of the roles in the community, labelling fragments of community behaviour that can be performed by enterprise objects wishing to join the community and satisfying constraints specified by roles. Note that a specific kind of an enterprise object is that of party, which is used to model an entity with some of the rights, duties and powers of a natural person [3]. This concept naturally represents many stakeholders in eHealth — individuals, healthcare providers, healthcare provider organisations and so on. Community behaviour is defined in the corresponding community contract which specifies the objective of the community, the roles in the community and the processes and interactions in which they are involved. In particular, the community concept has been valuable in defining the scope of policies that apply to specific healthcare administrative domains and to the roles in the domain. An enterprise specification of an eHealth system can then be described in terms of one or more related communities — arranged in
316
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
a hierarchical or federated structure. The hierarchical representation is supported by the capability of one community to fill a role in a high-level community, by being considered a composite enterprise object that also represents a community, called a community object. The federation can be supported by using the concept of a domain, which is a special kind of community in which one role has a controlling relationship to other objects in the domain. Federation is then specified as a community of two or more domain communities, cooperating to achieve a shared objective of the federation. This approach to segmenting a complex eHealth organisational landscape into clearly defined administrative boundaries and relationships between them was beneficial in the eMedication domain, in the expression of the ETP reference architecture, as well as for the specification of the complex national eHealth authentication service (NASH) landscape described in Sections 4 and 5. In summary, the concept of community provides useful insights into the requirements elicitation processes and subsequent business analysis and business architecture specifications. In addition to the community related concepts, the NEHTA Interoperability Framework also refined the general concept of service, introduced in part 2 of the ODP-RM [1], from the enterprise viewpoint. It defines a business service as ‘a particular abstraction of behaviour expressing the guarantees of service providers, defined in terms of the service offers which, if accepted by service users (as a requestor for service delivery) form the basis of a service level agreement’. The guarantees involve policies that apply to the service providers and, if a consumer accepts the service offer, certain policies are also applied to the consumer. Further, the Interoperability Framework identifies nine high-level categories of organisational interoperability patterns, such as standardised business processes, policy patterns, monitoring and auditing, cost, and value assessment, which are expressed using the concepts from the ODP Enterprise Language. This ensures a pragmatic approach to addressing specific problems, while preserving precision of expression. Given the ongoing nature of the NEHTA Interoperability Framework, it is anticipated that new organisational patterns will be identified and documented as they emerge. 3.2. Information interoperability The information interoperability is concerned with the modelling and representation of information in healthcare, or the ‘static semantics’, as referred to in the HL7 standards. This is traditionally the area of healthcare informatics, and the NEHTA Interoperability Framework provides only a minimal set of information concepts. The rationale for this was the need to accommodate the description of multiple approaches from the health informatics standards, most notably HL7 standards and CEN EHR specifications. The information perspective is therefore considered to be a common reference point identifying the core information concepts and their relationships. It is worth noting that this is the approach recently taken by the HL7 SAIF initiative, in order to identify a ‘canonical model’ of an information framework, consisting of clinical concepts, healthcare data types, clinical terminologies, event summaries and electronic health records. Many information models can be produced using the core clinical information concepts but they do not stand alone, and must be interpreted in the context of one or more business services, stated in the organisational perspective. The information language concepts are based on a subset of ODP information viewpoint modelling concepts, namely the concept of information objects and invariant schema. Dynamic schemas and a more comprehensive set of clinical modelling concepts based on various clinical informatics results are likely to be proposed in the next version. It is also important to make a distinction between the requirements for electronic representation and processing of electronic data, and the requirement to support interpretation by clinicians for clinical purposes. Although electronic data and electronic processing
can facilitate some simple inference approaches, as in clinical terminologies or decision support systems, certain forms of information will always be processed by clinicians. This is an important issue to take into account when implementing clinical information processing systems, to make allowance for information to be represented in both structured and unstructured forms, for use by both IT systems and humans [5]. Finally, the Interoperability Framework introduces several categories of information patterns to facilitate a shared understanding about important information concerns and approaches and to ensure consistency of NEHTA outcomes and subsequent alignment within the broader jurisdictional community. Examples are information policies, information transformation, information temporal dependencies and so on. These information patterns are based on information modelling concepts introduced earlier. 3.3. Technical interoperability In terms of the technical interoperability language, several ODP concepts from the RM-ODP Foundation and Architecture standards, mostly computational viewpoint concepts [1,2] were used. Examples are the ODP concepts of action, behaviour, interaction and computational service (referred to as technical service in the Interoperability Framework). The technical interoperability language also includes a limited number of other technical concepts — derived from these core concepts, but based on current eHealth applications, such as the concept of message. Future versions of the Interoperability Framework are expected to incorporate additional concepts, which will partly be driven by the needs of the relevant stakeholders, as well as the concepts from the engineering and technology viewpoints, as required. Further, the ODP concepts can be used to support expression of various architectural styles, such as service-oriented or eventoriented architectures and these are considered as special kinds of technical interoperability patterns in the Interoperability Framework. The value of these emerging architecture styles in an eHealth environment is in driving a shift towards a focus on business functionality. This should allow purchasers to better specify the expectations of IT systems — reflecting their business needs, rather than purchasing only that which is available in the market. Note however, these architecture styles alone are not sufficient to ensure technical interoperability. What is required is strong governance for architecture development to ensure a continuum between the requirements and the organisation, information and technical interoperability concerns. It is therefore a combination of technical solutions and organisational patterns, such as change management, education, awareness and governance mechanisms, that will ensure the longevity, sustainability and realisation of the true benefits from eHealth systems. Other technical patterns are technical quality, service delivery channels and style of component interactions [5]. 3.4. HL 7 SAIF influences The NEHTA Interoperability Framework is now being augmented with the developments from the HL7 Service Aware Interoperability Framework (SAIF) [7]. Incidentally, both the NEHTA Interoperability Framework and the initial SAIF proposal (which preceded our involvement in the SAIF standardisations) have taken RM-ODP as an architecture framework to support interoperability approaches. The decisions in both of these initiatives were motivated by the fact that the family of ODP standards are de-jure ISO/IEC/ITU-T standards known for their stability, semantic precision and a well-developed conformance framework. SAIF approach adopts the use of the ODP viewpoints to structure eHealth interoperability specifications and augments them with further levels of refinement to reflect specific sub-groups of stakeholders
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
within the viewpoints. These are captured through the use of three interoperability perspectives, each with its own way of representing concepts, reflecting the preferences of the respective subject matter experts. These are conceptual perspective — capturing artefacts focused on problem space and thus of interest to and readable by domain experts, analysts and stakeholders, logical perspective — capturing artefacts representing traceable translations of conceptual level artefacts into a form useful for architects and ICT experts, implementable perspective — technical specifications for consumption by technical architects and developers, typically based on implementation standards. For example, in the information viewpoint, three broad groups of stakeholders are identified, as follows: • In the conceptual perspective, clinicians and business analysts who, for example, use conceptual maps or high-level UML models to represent key clinical concepts and their relationships. • In the logical perspective, clinical informaticians and terminologists, as well as information architects, who express the same concepts in a more formalised way, e.g. using structured documents, constraints and clinical terms using formal representations such as UML modelling [18] and clinical terminology tools such as SNOMED-CT tools [19], essentially refining the conceptual concepts identified above. • In the implementable perspective, technical architects and developers who further refine the logical specifications above using implementable standards such as SOAP, WS-security [21] or Clinical Document Architecture (CDA) [20] schemas and so on. The final, fully implemented specifications are eventually produced by a specific vendor, reflecting the specific technology chosen to implement the solution specification across the three layers above. A vendor specification will typically state how a particular product implements the specification, including the level of conformance they are claiming with the specification. Note that a logical specification can be a ‘reference’ specification that can be further specified with details of the environment in which it is to be deployed or implemented, including the use of a specific technology of choice. For example, a generic ETP solution specification can be the basis for a number of compliant solution architectures, e.g. an ETP solution architecture for the community sector, involving community pharmacies and general practitioner clinics who have their own choice of technology options at any point in time. In addition, the ETP reference architecture can also be tailored for the needs of a hospital setting, resulting in a different solution specification with different requirements, for example, security and policy settings, reliability and so on. Finally, a solution specification should be produced with a clear set of conformance points, particularly if they are developed for the purpose of driving national eHealth interoperability outcomes. The use of the RM-ODP's conformance framework provides a sound foundation to express such conformance points so that software vendors and system integrators can state their product specification in a way that can facilitate third-party testing. This is of particular importance where conformity assurance is required by regulation or governing authorities as is increasingly the case in eHealth specifications. 4. Electronic Transfer of Prescription specification NEHTA, in consultation with a wide range of stakeholders, has developed a set of specifications for the Electronic Transfer of Prescriptions (ETP) in Australia. These specifications have been provided as input into a standardisation process that is currently being conducted by Standards Australia. National standards are expected to emerge from this process for a set of electronic clinical documents and for a set of web service interfaces by which these electronic clinical documents will be transferred between prescribers and dispensers. These national standards are
317
required in order to meet national objectives to improve the efficiency and clinical safety of the processes by which consumers receive their prescribed medications, and to improve the way consumers experience these processes. ETP is concerned with transferring electronic clinical documents between prescribers and dispensers according to nationally agreed standards. An enterprise viewpoint of ETP is therefore only a ‘filter’ applied to a much broader ‘eHealth enterprise’ — in other words the ETP enterprise viewpoint specification defines scope and purpose of the ETP system to be developed as part of its environment, which is the broader ‘eHealth enterprise’ at the national level. While ETP has a rather limited scope, it does intersect with other elements of this eHealth enterprise — for example, the electronic prescription and dispense records transferred by ETP will also contribute to a comprehensive personally controlled electronic health record. 4.1. ETP enterprise viewpoint The adoption of the RM-ODP Community concept in specifying the enterprise concerns of ETP made it possible to focus on the ETP objectives and how a set of participating parties cooperate to achieve them, while recognising that other aspects of the behaviours of these ETP Participants will be further specified as part of other national eHealth initiatives. The following diagrams depict a simplified description of ETP communities. Note that the actual ETP standards that will be developed by Standards Australia are more detailed in terms of the enterprise viewpoint, as well as the information and computational viewpoints. Note that NEHTA has established its own visual representation of a community contract as an ellipse. Fig. 1 shows the ETP Participants community in terms of the Community Roles that represent organisations and individuals and the key structural relationships between them. A primary purpose of this community model is to help stakeholders achieve a common understanding of the types of individuals and organisations involved in ETP and their key commercial or organisational relationships. NEHTA also specifies (not included here) policies and behaviours for these community roles that express requirements that the parties must meet in order to fulfil these roles. The community roles shown in Fig. 1 are: • Governance Authority: Defines the policies that govern the behaviour of all the participants in the ETP community. • Prescription Subject: The individual for whom a prescribed medication is intended. • Participating Prescriber: An individual who provides healthcare and who creates prescriptions in accordance with all relevant legislative, regulatory and professional requirements. A Participating Prescriber shall participate in ETP Services as the representative of an identified Participating Prescriber Organisation. The role of Participating Prescriber may be fulfilled by parties that are either hospital or community-based healthcare provider individuals. • Participating Prescriber Organisation: A healthcare organisation that is represented by one or more Participating Prescribers. • Participating Dispenser: An individual who provides healthcare and who dispenses a prescription in accordance with all relevant legislative, regulatory and professional requirements. A Participating Dispenser shall participate in ETP Services as the representative of an identified Participating Dispenser Organisation. This role may be fulfilled by pharmacists and other authorised healthcare providers that are either hospital or community based. • Participating Dispenser Organisation: A healthcare organisation that is represented by one or more Participating Dispensers. • Prescription Exchange Service (PES) Provider: An organisation that provides a Prescription Exchange Service (PES) by which electronic prescriptions (created by Participating Prescribers) and electronic dispense documents (created by Participating Dispensers) are
318
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
Fig. 1. ETP Participants community.
made available to Participating Dispensers. The PES reflects the state of the prescription, thereby blocking access to prescriptions that have been cancelled, are expired, or have been fully dispensed. • Subject Agent: An individual who acts on behalf of a Prescription Subject. • Medications Supply Manager: An organisation that acts on behalf of (and with the consent of) Prescription Subjects to request the dispensing of their medications. Note the use of a community object in this model. As mentioned earlier, this concept is used to represent the community as a separate enterprise object, so that it is possible to model how the ETP community exists as part of the overall eHealth environment in Australia. Another ETP community is ETP Services community — shown in Fig. 2. This community specifies how participants interact with the supporting ETP system roles. A key characteristic of the ETP Services community is that it is built around a commercially operated
Prescription Exchange Service (PES). Note the use of the RM-ODP Interactions to model PES business service and other business services as well as RM-ODP Artefacts, which model the exchange or referencing of data objects in the context of interactions. For example, the e-Prescription document Artefact is created through the ePrescription business service (involving the Electronic Prescribing System and Prescription Exchange roles as initiators and responders) and the same document is used by the Electronic Dispense System role, as part of a subsequent e-Dispensing business service. It is important to highlight the fact that the same parties fulfil roles in both the ETP Participants and ETP Services communities, as shown in Fig. 2. This mechanism allows the ETP community to be effectively modelled as a combination of both the ETP Participants and ETP Services communities. Further, Fig. 2 describes a number of business services, as listed below. • E-Prescribing: A service provided for the management e-Prescriptions — this service provides three service functions:
of
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
○ Submit e-Prescription to a Prescription Exchange. ○ Cancel e-Prescription. ○ Retrieve e-Prescription. • E-Dispensing: A service provided for the dispensing e-Prescriptions. This service provides four service functions: ○ ○ ○ ○
Retrieve e-Prescription. Cancel e-Prescription. Store Dispense Record. Cancel Dispense Record.
of
319
• Owed Prescription: A service to allow a dispenser to request that an identified prescriber create an e-Prescription (an ‘owed prescription’) that confirms an instruction previously given by that prescriber to that dispenser (in a form other than a prescription). It also provides for the prescriber to respond to these requests by providing the dispenser with an electronic prescription notification. • Notify Supply Manager: A service to allow a prescriber to notify a facility that manages the supply of medications for a patient (such as an aged care facility) of the availability of a new e-Prescription. • Contract Dispensing: A service to allow a facility that manages the supply of medications for a patient (such as an aged care facility) to request the dispensing and supply of a medication.
Fig. 2. ETP Services.
320
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
In addition to the community roles defined in Fig. 1, the following community roles are shown in Fig. 2: • Electronic Prescribing System (EPS): A component of a clinical information system that is used by a Participating Prescriber to prescribe medications. An Electronic Prescribing System is operated by an identified Participating Prescriber Organisation. • Electronic Dispensing System (EDS): A component of a clinical information system that is used by a Participating Dispenser to dispense medications. An Electronic Dispensing System is operated by an identified Participating Dispenser Organisation. Typically the Prescription Subject instigates the dispensing process by attending the pharmacy of their choice and requesting that an identified prescription be dispensed. The alternative is that the request to dispense is sent electronically by a Supply Request Management System (defined below) to the EDS — policy settings only permit this usage where the Prescription Subject is the resident of a healthcare facility and has consented to that facility managing the supply of their medications. • Prescription Exchange (PE): A system that manages the electronic documents and records that support the ability to prescribe and dispense medications. A Prescription Exchange contains — for each prescription created as an electronic document — the electronic prescription document plus its associated electronic dispense documents. A Prescription Exchange also reflects the ‘dispensing state’ of each of these prescriptions. • PE Operator: An organisation that operates a Prescription Exchange. • EPS User: An individual user of an Electronic Prescribing System. • EDS User: An individual user of an Electronic Dispensing System. • Supply Request Management System: A system that manages the supply of medications (on behalf of consenting Prescription Subjects) by accepting notifications that indicate that an electronic prescription (for a consenting Prescription Subject) has been sent to a Prescription Exchange and requesting an EDS to dispense that electronic prescription. • Supply Management System Operator: An organisation that operates a Supply Request Management System. The behaviour of organisations and individuals in the ETP community is primarily specified by the policies associated with the ETP Participants community, providing a basis for expressing commercial relationships between these participants, including business contracts. On the other hand, the behaviour of the participants in the ETP Services community is primarily specified using UML activity diagrams, in which the partitions (swim lanes) represent community roles. An example is shown in Fig. 3 that depicts the aspects of the prescription process that are relevant to ETP. 4.2. ETP logical service specification — computational viewpoint A UML 2.3 compliant model was developed to represent the ETP technical services in a way that is independent of implementation technologies. A key aspect of NEHTA's approach in modelling these logical ETP technical services was the use of UML Collaboration to represent the technical services and UML Interfaces to represent the interfaces by which these services are accessed. Fig. 4 identifies service roles in the collaborations and, through typing, specifies the interfaces that must be provided by components that act in these service roles. Fig. 4 also shows the correspondence between the ETP technical services of the computational viewpoint and the business services of the enterprise viewpoint (modelled as interactions). The ETP technical service interfaces are shown in Fig. 5. These represent a simplification of the actual ETP interfaces proposed for use in Australia. Each interface specifies the functions of the service using UML operations and the operations make use of the information objects shown in the information model described in Section 4.3.
The ETP logical service specification also includes a view of the expected deployment of ETP systems. This model uses UML components, as shown in Fig. 6. Note the use of UML provided and the required interface associated with UML components, which are used to define the interactions between the components according to the technical services provided by the components. In addition, each of the UML components has correspondence to the community roles introduced in Fig. 2. A summary of the computational viewpoint, a ‘Service Architecture’ (represented as a UML collaboration) is shown in Fig. 7. This depicts the logical ETP Services and shows correspondence between the logical service models (elements of a computational viewpoint) and the community models (elements of the enterprise viewpoint). 4.3. ETP logical service specification — informational viewpoint The informational viewpoint was primarily developed to support the ETP computational logical service specification by modelling the message types referenced by the ETP technical services. A UML 2.3 compliant information model was developed to represent these messages types (message types were modelled using the UML dataType stereotype). Fig. 8 shows, as an example, the Prescription Submission message type that is sent by an Electronic Prescribing System to a Prescription Exchange (via the E-Prescribing interface). The correspondence between information viewpoint elements (in this case data types) and enterprise viewpoint elements (in this case artefacts) is also shown. 5. National Authentication Service for Health The National Authentication Service for Health (NASH) is a national approach to credentialing to support authentication between health participants. NASH provides an e-authentication framework, a Public Key Infrastructure (PKI) framework and a credentialing service based on PKI digital certificates and hardware security tokens (smartcards). While the immediate concern for NASH is to deliver a centralised capability for economies of scale, a national approach to authentication and credentialing must be cognisant of Australia's federated political environment, while also meeting the Australian Federal Government's stringent requirements for PKI as embodied in the Australian Government Gatekeeper Framework [13]. 5.1. Requirement for modelling patterns of interactions — difficulty with the current ODP approaches The NASH Identity System supports assertion of identity claims between health participants in which a Subject asserts a claim for evaluation by a Relying Party. This can be regarded as an Assert Claim pattern, as shown in Fig. 9. This behaviour pattern will feature in most (if not all) contexts where one or more parties are involved in an electronic exchange. In RM-ODP, a pattern is defined as follows: ‘bX > Pattern: The abstract specification of a composition of objects that results in any instance of the composition having a given property, named by X’. This definition is a generalisation of the well-known concept of a design pattern (note that bX > is the pattern name, for example, the factory design pattern). Unfortunately, this concept is not yet supported in the UML4ODP standard. Initially it seemed that patterns could be supported through the concept of the ODP community object. A community object is an enterprise object that represents a community and can be used to fulfil roles in higher level communities as required. The idea was to first specify a community object defining a pattern (using the EV_RefinesAsCommunity association between the community defining the pattern and the community object). This community object can then be reused in a higher level community by filling relevant roles in that community
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
Fig. 3. Prescription process.
321
322
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
Fig. 4. ETP logical services.
(through a fulfils role association EV_FulfilsRole between the pattern community object and the respective community roles EV_CommunityRole in the higher level community). However the limitation of this approach is that patterns can only be expressed through objects, rather
than establishing patterns of interactions through roles. The related problem with this modelling approach is that it is not possible to instantiate multiple instances of the same ‘community pattern’ and map roles within the community that use the pattern in the role instances
Fig. 5. ETP technical service interfaces.
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
Fig. 6. Expected deployment of ETP systems.
Fig. 7. ETP Services architecture.
323
324
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
Fig. 8. Prescription submission message type.
described in the community pattern. Linington came to a similar conclusion in his 2010 paper [14]. 5.2. An alternative approach — use of UML collaboration Our solution was to use UML Collaboration to model patterns of behaviour between community roles. As a result, wherever roles interact in our system, such as in the provision and use of business services, this is reflected through collaborations that define collaboration roles, the communication between those roles and collaboration artefacts. The UML Collaboration is a UML Classifier and also allows composing of patterns of behaviour, using other collaborations. Wherever a pattern of behaviour is used, it is modelled as a CollaborationUse that identifies the type of Collaboration. The CollaborationUse has RoleBinding associations to the entities that participate in the Collaboration. There can be more than one instance of a CollaborationUse, allowing the pattern of behaviour to be reused in different contexts within a community. It is also possible to specialise a Collaboration for a particular context, thus improving the applicability and adaptability of behavioural patterns and thereby allowing the establishment of a behavioural pattern catalogue. The need to compose community behaviour through the re-use of patterns of behaviour (e.g. business use-cases) is imperative for efficient and rational engagement with stakeholders when building large-scale interoperable systems. The UML Collaboration provides such an approach and supports modelling of business scenarios and business use cases within a community. The UML Collaboration allows examination of a specific aspect of the community (for example, a particular business scenario) and calls into focus the enterprise objects and parties fulfilling community roles, and the relationships between them. A typical business scenario will involve instances of re-usable business
use cases modelled as UML Collaboration and CollaborationUse with role bindings to the community roles and the parties fulfilling those roles. NEHTA has established an eHealth community ‘persona’ catalogue, to support development of meaningful business scenarios where a persona (for example, ‘Dr Stork the obstetrician’) represents a specific instance of a party and fulfils various roles within the communities in which it participates. The benefit of this approach is that the business scenario represented as a Collaboration provides a rich but scoped contextual story for the parties and the roles they are fulfilling, while the use cases (re-usable behavioural patterns) define the interactions and processes that occur between roles and enterprise objects (typically systems and artefacts) within that context. While UML Collaboration was a solution that provided the ability to compose and re-use patterns of behaviour, it seems logical that a similar need would arise wherever an ODP community pattern is defined. In other words, it should be possible to re-use and parameterise an ODP community template within other communities (support multiple instances), and also refine or specialise a community. An example of such a concept is a ‘committee’ community pattern. The abstract community pattern ‘committee’ could be defined with the roles ‘chair’, ‘voting member’, ‘non voting member’, ‘secretariat’ and associated policy and process patterns. As stated above, UML4ODP does not provide explicit support for either refinement or re-use of the ‘committee’ pattern community just described; for example, a standards body containing a number of sub-committees. Consideration ought to be given to enhancing UML4ODP to support composition and specialisation of community patterns and the instantiation and binding of the community modelling elements to those within the communities using them, as also identified by Linington [14]. It is worth noting that the UML Collaboration, if used without RM-ODP, can support patterns of basic behaviour characterising
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
325
Fig. 9. Assert Claim pattern.
communication between entities, but this does not directly consider behavioural constraints stated in enterprise policies nor how they can affect pattern use. Our approach however does provide initial support for constraints through role binding to community roles and enterprise objects. Further elaboration on this topic is an area of future research. While modelling the NASH using UML4ODP, it also became evident that policy ought to be a first class EV_Object so that it may participate in processes and interactions and be able to express state transition (for example, in state diagrams) just like other enterprise objects. It is difficult to think of a situation where one would be concerned with modelling policy within a community without there also being a need to reflect that policy as one or more enterprise object artefacts. For the NASH, there is the need to manage PKI policies as artefacts. Such policies will exist in a number of states, such as proposed, approved, retired and superseded. We suggest refactoring the UML model for EV_Policy to be a specialisation of EV_Object. An additional observation made in respect of UML4ODP is the definition of EV_CommunityObject and EV_FulfilsRole. It is currently not possible to have a community object fulfilling a role directly in a community, given the way EV_CommunityObject and EV_FulfilsRole are currently defined. Two immediately obvious remedies are to either change EV_CommunityObject to specialise EV_Object or to modify EV_FulfilsRole to allow the association between the ≪EV_CommunityObject≫ class and ≪EV_Role≫ class. 5.3. Assert Claim collaboration The Assert Claim collaboration shown in Fig. 9 depicts a collaboration of roles interacting to make claims in accordance with Kim Cameron's Laws of Identity paper [12]. The diagram shows a Subject role as interaction initiator providing a claim of something to a relying party role as the responder. This diagram also depicts the claim
participating within the interaction as an artefact. The various states of the claim that can exist within this interaction are also shown, without needing to delve into the details of how this occurs within a process. 5.4. Identity system community An abstract community representing an identity system for health is shown in Fig. 10. This identity system community embodies concepts from Kim Cameron's Laws of Identity [12] applied to a PKI model where enrolment and credentialing are separate functions, as is the case for the NASH. The six roles (Subscriber, Digital Subject, Registration Authority, Issuing Authority, Relying Party and Policy Authority) shown in the community diagram depict the primary community roles of most significance to the stakeholder audience for this community. Additionally, the relationships between the roles are expressed through UML CollaborationUse. These collaborations represent the primary behaviours and business drivers for the existence of that community role. Note that there is a distinction between the community role of Subscriber and that of Digital Subject. The relationship here is one of delegation, where the party fulfilling the Digital Subject role in a given situation is typically either the same entity fulfilling the subscriber role, a delegated IT system, or other agent under the direction of the Subscriber as the principal. This role separation allows different policy rules to apply. Fig. 10 also depicts the re-use of patterns of behaviour. The Assert Claim pattern provides for the assertion of some claim and is expressed with a UML CollaborationUse. Three instances of the Assert Claim collaboration are depicted: 1. Enrolment :Assert Claim, whereby a Subscriber claims evidence of identity for enrolment purposes with a Registration Authority. 2. Credential Use :Assert Claim, whereby a Subscriber claims their digital identity through a credential with a relying party.
326
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
3. Credential Status :Assert Claim, whereby the Issuing Authority claims the status of some credential through an artefact such as a Certificate Revocation List. The UML role bindings demonstrate how the community roles and objects participate in the patterns of behaviour and the ensuing interactions modelled by the collaboration. The management of policy is also depicted as a re-usable pattern of behaviour. In our identity system community, the management of policy is strictly defined to ensure that all relying parties have the necessary assurance they need to trust Credential claims. Two instances of the pattern of behaviour for policy management are used in different contexts: 1. Credential :Policy Management, whereby the Policy Authority manages Certificate Policy. 2. Subscriber :Policy Management, whereby the Registration Authority manages its Subscriber Policy. The final collaboration :Credentialing depicts enterprise objects Credentials (Identity Claims) being issued to Subscribers acting as
custodians with collaborative processes that involve Registration Authorities acting as Sponsors and Issuing Authorities acting as Issuers. The diagram does not depict all the collaborative processes involved, just that there is a collaboration of entities for the purpose of credentialing and that this collaboration is significant in business terms to the stakeholder audience. While not shown in this paper, the definition of the : Credentialing collaboration contains a number of inner collaborations covering business aspects of credentialing, including delivery/fulfilment, activation, post issuance update, revocation and renewal.
6. Participation in multiple communities The ETP enterprise specification shows how an Individual Provider, modelled as a Party, participates in two ETP communities — one concerned with business relationships, that is the ETP Participation community shown in Fig. 1, and another concerned with users accessing the underlying IT systems, that is the ETP Services community shown in Fig. 2. This approach provides a clear delineation of two different concerns in eHealth systems, while supporting the expression of real world
Fig. 10. Identity system community.
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
situations in which an Individual Provider is indeed both a Prescriber and System User. While the example shown in Fig. 1 allows us to depict the specific roles that this party fills in both communities, the situation can be quite complex if there is a need to demonstrate how the same provider participates in other communities through fulfilling specific roles therein. In order to support this expression, we use the concept of interface role to represent only those roles that are of concern for describing the role-filling relationship, while hiding other roles, which are perhaps of less interest from the point of view of users of services provided via the interface roles. Fig. 11 shows a simple model of how the same party, an Individual Provider, fulfils roles in multiple communities – two ETP communities and two NASH communities. Note that the UML4ODP does not distinguish between an interface role in a community and other roles in the community, so we denote this through the ‘exposed by’ association. 7. Conclusions This paper summarises NEHTA's experience of using RM-ODP standards to provide the architecture foundation and interoperability guidelines to support building eHealth systems at a national level. The mature set of ODP standards provides many components that can inform the design and build of such systems and it is encouraging to see that the key HL7 standardisation efforts [16] are increasingly making use of the ODP standards. The ODP standards were also used in another eHealth standard, namely Health Informatics – Service Architecture (HISA) [15], however our usage makes more extensive use of the ODP Enterprise Language concepts [3]. In terms of modelling, our emphasis has therefore been on the enterprise viewpoint, because this is where the ODP Enterprise Language provides a unique ability to precisely describe the business context needed to thoroughly understand the implications of policy and administrative domains on the structure of interactions between users and systems. While we relied on the use of UML modelling to describe the computational and information viewpoint concerns, in future we will consider whether certain elements of the computational language would be of value, in particular the concepts of compound binding and streams. We also believe there is value in considering the use of ODP functions as well as certain concepts in
327
engineering language. In future, we will establish a more formal rule for correspondence between viewpoints. We have identified some areas where the ODP standards need further refinement. One of them is an explicit support for services in the enterprise viewpoint. One option is to use interface roles to support the expression of service offerings. Another requirement is to better support the expression of pattern definitions and pattern use in a similar way to UML collaboration diagrams, but with well-defined semantics to reflect both the enterprise and computational aspects of behaviour. References [1] ISO/IEC IS 10746–2, Information Technology — open distributed processing — reference model: foundations, Also published as ITU-T Recommendation X.902, 2010. [2] ISO/IEC IS 10746–3, Information Technology — open distributed processing — reference model: architecture, Also published as ITU-T Recommendation X.903, 2010. [3] ISO/IEC IS 15414, Information Technology — open distributed processing — enterprise language, Also published as ITU-T Recommendation X.911, 2003. [4] ISO/IEC IS 19793, Information Technology — open distributed processing — use of UML for ODP system specifications, Also published as ITU-T Recommendation X.906, 2009. [5] NEHTA Interoeprability Framework 2.0, NEHTA 2007, viewed 18 August 2011, http://www.nehta.gov.au/component/docman/doc_details/391-interoperabilityframework-v20. [6] NEHTA — National E-Health Transition Authority, viewed 18 August 2011, http:// www.nehta.gov.au/. [7] HL7 Services Aware Interoperability Framework, http://en.wikipedia.org/wiki/ HL7_Services_Aware_Interoperability_Framework. [8] Australian Government Information Management Office (AGIMO), viewed 18 August 2011, http://www.finance.gov.au/agimo/index.html. [9] U.S. Department of Defense, The Department of Defense Architecture Framework (DoDAF) Version 2.02, viewed 18 August 2011, http://cio-nii.defense.gov/sites/ dodaf20/. [10] FEA Consolidated Reference Model Document Version 2.3, October 2007. [11] The Open Group, TOGAF Version 9, viewed 18 August 2011, http://www. opengroup.org/togaf/. [12] K. Cameron, The Laws of Identity, 2005, viewed 18 August 2011, http://www. identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf. [13] Department of Finance and Deregulation, Australian Government Information Management Office, Gatekeeper Public Key Infrastructure (PKI) Framework, viewed 18 August 2011, http://www.finance.gov.au/e-government/securityand-authentication/gatekeeper/index.html. [14] P.F. Linington, The stereochemisty of enterprise objects, Proceedings of the WODPEC workshop, The Fourtheen EDOC Enterprise Computing conference, 25–29 Oct 2010, Vitoria, Brasil, 2010.
Fig. 11. Participation in multiple communities.
328
A. Bond et al. / Computer Standards & Interfaces 35 (2013) 313–328
[15] ISO 12967–1/2/3 — Health Informatics — Service Architecture — Parts 1, 2 and 3 (Enterprise, Information, Computational viewpoints), 2009. [16] Paraphrased from a presentation by Sir Muir Gray, Director UK NHS National Knowledge Service & NHS Chief Knowledge Officer, Medifo Brisbane presentation, 2007. [17] http://www.hl7.org.au/CDA.htm. [18] UML Infrastructure, http://www.omg.org/spec/UML/2.4.1/. [19] http://www.ihtsdo.org/snomed-ct/. [20] http://www.hl7.org/implement/standards/cda.cfm. [21] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.
Andy Bond has driven the interoperability agenda at the National E-Health Transition Authority (NEHTA) for several years covering organisation, information and technical aspects of system design and interconnectivity. Prior to NEHTA, Andy was Chief Scientist at the Distributed Systems Technology Centre (DSTC) responsible for research strategy, engagement and market transition. Special areas of interest include complexity, middleware, enterprise architectures and interoperability. His work has included interoperability frameworks, large-scale national and international architectures and various novel distributed systems innovations.
Andrew Hacking has been involved in eHealth since 2008, working predominately in the area of Information Security with a focus on authentication and transaction security with the National E-Health Transition Authority (NEHTA). He is currently co-chair of the Standards Australia IT-014-04 Health Informatics Information Security subcommittee. Prior to NEHTA, Andrew specialised in the design and development of security products and solutions for technology vendors and government including Computer Associates, SafeNET and the Australian Defence Signals Directorate.
Zoran Milosevic has been working for the National E-Health Transition Authority (NEHTA) since 2005, mainly in the area of eHealth interoperability. He was a co-author of the NEHTA Interoperability Framework and a contributor to the HL7 Service Aware Interoperability Framework. Before NEHTA, Zoran worked for the Distributed Systems Technology Centre (DSTC) and was involved in the standardisation of the RM-ODP and several OMG standards. He was the founder of IEEE's Enterprise Distributed Object Computing conference and has interests in enterprise modelling, policy languages and event-based systems. He recently co-authored a book ‘Building Enterprise Systems with ODP: an Introduction to Open Distributed Processing’.
Andrew Zander has been working at the National E-Health Transition Authority (NEHTA) since 2007 and is currently the Lead Architect for Product and Solutions Development. He was the NEHTA architect responsible for developing specifications for a national approach to prescribing and dispensing medications based on electronic prescriptions and dispense records. Before joining NEHTA, Andrew worked for many years, primarily in the telecommunications industry, both as a solution architect and a product architect.
