eforms and templates - health.vic/media/health/files... · eforms and templates 30 march 2016...

National E-Health Transition Authority

nehta Service Referral Reference Architecture

eForms and templates

30 March 2016

Version 1.0

Approved for external use

National E-Health Transition Authority Ltd

Level 25, 56 Pitt Street

Sydney, NSW 2000

Australia

www.nehta.gov.au

Acknowledgements

Council of Australian Governments

The National E-Health Transition Authority is jointly funded by the Australian Government and all State and Territory Governments.

HL7 International This document includes excerpts of HL7® International standards and other HL7 International material. HL7 International is the publisher and holder of copyright in the excerpts. The publication, reproduction and use of such excerpts is governed by the HL7 IP Policy (see http://www.hl7.org/legal/ippolicy.cfm) and the HL7 International License Agreement. HL7 and CDA are registered trademarks of Health Level Seven International.

Disclaimer

The National E-Health Transition Authority Ltd (NEHTA) makes the information and other material (‘Information’) in this document available in good faith but without any representation or warranty as to its accuracy or completeness. NEHTA cannot accept any responsibility for the consequences of any use of the Information. As the Information is of a general nature only, it is up to any person using or relying on the Information to ensure that it is accurate, complete and suitable for the circumstances of its use.

Document control

This document is maintained in electronic form and is uncontrolled in printed form. It is the responsibility of the user to verify that this copy is the latest revision.

Copyright © 2016 National E-Health Transition Authority Ltd

This document contains information which is protected by copyright. All Rights Reserved. No part of this work may be reproduced or used in any form or by any means—graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems—without the permission of NEHTA. All copies of this document must include the copyright and other information contained on this page.

http://www.nehta.gov.au/

http://www.hl7.org/legal/ippolicy.cfm

Service Referral Reference Architecture eForms and templates

30 March 2016 Approved for external use 3 of 21 Version 1.0

Document information

Key information

Owner Head of Delivery

Contact for enquiries NEHTA Help Centre

t: 1300 901 001

e: [email protected]

Product version history

Product

version

Date Release comments

V1.0 30/3/2016 Approved for external use

mailto:[email protected]

nehta

4 of 21 Approved for external use 30 March 2016 Version 1.0

Table of contents

1 Introduction ....................................................................................................... 5

1.1 Purpose ...................................................................................................... 5

1.2 Intended audience ....................................................................................... 5

1.3 Scope ......................................................................................................... 5

1.3.1 Background ..................................................................................... 5

1.3.2 Scope ............................................................................................. 6

1.3.3 Out of scope .................................................................................... 7

2 Enterprise viewpoint .......................................................................................... 8

2.1 eForms community ...................................................................................... 8

2.1.1 Overview. ....................................................................................... 8

2.1.2 Community objectives ...................................................................... 8

3 Computational Viewpoint ................................................................................... 9

3.1 Introduction ................................................................................................ 9

3.2 Design constraints ....................................................................................... 9

3.3 Design ........................................................................................................ 9

3.3.1 Approach ........................................................................................ 9

3.3.2 Design overview ............................................................................ 10

3.3.3 Security ........................................................................................ 11

3.3.4 Referral Manager ........................................................................... 11

3.3.5 CMS Adapter ................................................................................. 14

3.3.6 Local Directory .............................................................................. 15

3.3.7 Referral UI .................................................................................... 16

3.3.8 Consumer Management System ....................................................... 16

3.4 Logical interface specification ...................................................................... 17

3.4.1 Referral Manager Registration interface ............................................ 17

Glossary ................................................................................................................... 20

References ............................................................................................................... 21



1 Introduction

1.1 Purpose

The purpose of this document is to provide a high-level architecture and logical

interface specifications to support the process of creating referral requests that

optionally include completed eForms1.

The interfaces detailed in this document are considered candidate interfaces based

on initial development and consultation. It is expected that stakeholder feedback

will further inform the process of refining these interface specifications.

1.2 Intended audience

This document is primarily intended for a technical audience.

1.3 Scope

1.3.1 Background

The document, Cross-organisation workflow coordination [WFC], addresses

“standards” 2 for the system interfaces used to manage the lifecycle of referral

processes, track their progress and exchange relevant documents. Those standards

are, however, independent of the service specific content of referral requests and of

the processes by which referral requests are created. The document Service

Referral Structured Content Specification [SRSCS] provides the logical specification

of the content of referral requests and this document provides specifications of

logical system interfaces used to create referral requests.

The efficiency and safety of any referral process is improved when the referral

sender provides, in their referral request, as much as possible of the information

that the referral receiver needs to assess that request. Wherever possible this

information should be semantically defined (by reference to standard information

models and terminologies) and machine readable.

In 2009 NEHTA published a set of eReferral specifications [eREF]. These

specifications defined:

One eReferral CDA document type.

One standard referral request template3 which specified that a referral

request must comprise one valid CDA eReferral document, with optional

attachments, packaged together with its digital signature and then

encrypted to form an SMD sealed message.

NEHTA subsequently procured implementations of these standards from the leading

vendors of software products used by GPs and private specialists. The same CDA

document type and referral request template were expected to be used for all types

of service and for all service providers. All these vendors “hardcoded” support for

1 In this document an eForm is any electronic form that can be filled out without being printed. This therefore includes everything from word processor “templates” to “smart forms” which enforce field and cross-field validation rules and can include externally sourced data at runtime. 2 The term “standard” is used to include both de facto and de jure standards. 3 In this document a referral request template is a specification of the set of elements (e.g. eForms, CDA documents, FHIR resources, etc.) that constitute a valid referral request.

nehta


these standards into their products – any extensions to the supported set of

semantically defined, machine readable, information requires new versions of these

products to be deployed.

This document describes a new approach – but one which continues to support the

use of the current CDA eReferral document, and the use of the proposed new CDA

Service Referral document (a CDA document type intended to address electronic

referrals to a broader range of health and human services).

The new approach is based on the premise that different referral receivers may

have different requirements for at least some of the information that they need

referral senders to provide them with. The architectural elements described in this

document support this by enabling a referral sender system to use the identity of

the service provider, the services that they provide, and the identity of the

organisation that operates the system used to deliver electronic referrals to the

target organisation4, to determine which referral request template to use. These

architectural elements also allow for referral request templates that require the

referral sender to include one or more completed eForms in any referral request.

Enabling the use of eForms does not mean that eForms must be used. More

generally, enabling a referral sender system to use different referral request

templates for different referrals does not prevent the same referral request

template from being used for many different referrals. NEHTA will publish a referral

request template that requires the referral sender to provide an instance of the

Service Referral CDA document type. This Service Referral CDA document type

(and the Service Referral Structured Content Specification from which it was

derived) was designed to be used for a wide range of services offered by a wide

range of service providers.

1.3.2 Scope

The key system roles, and their relevant functions, that are discussed in this

document include:

Consumer management system (CMS) – for example a clinical information

system. The functions include:

o Selecting the record of the consumer who is the subject of the referral

and establishing a context for the subsequent supply of information to

be included in a referral request for that consumer.

o Launching a user interface (UI) to select a referral receiver and to

provide the information that they require in a referral request.

o Providing data on request to auto-populate referral requests.

o Storing and retrieving referral documents.

o When requested by a user, providing them with notifications and

reminders to help them track the progress of any referral processes.

Referral Request Manager. The management of referrals may be seen as a

“non-core” function of a CMS. Specialist service providers therefore provide

“plug-in” components to manage referrals. The functions include:

4 More precisely, the referral sending system determines the referral request template to be used based on an expression that matches one or more of the following fields of an ELS interaction record for the referral receiver: identity of the referral receiver, service category, service interface, endpoint address, and the identity of the organisation that operates the endpoint to which referrals are be sent.



o Retrieving eForm definitions from eForms Servers.

o Processing eForms – presenting the graphical user interface necessary

for users to complete eForms, auto-populate fields, and validate data

against eForm definitions.

o Implementing the behaviour specified in the Cross-organisational

Workflow Coordination document to: manage the life-cycle of referral

processes, track the progress of referral processes and exchange

referral documents with the referral receiver.

Local Directory. The maintenance of a local directory that is used for

referrals and other point-to-point communications may also be seen as a

“non-core” function of a CMS. Providers of directory services may therefore

provide a “plug-in” directory component that can be used to support

referrals. The functions include:

o Allow users to search for and select referral receivers.

o Matching the capabilities and preferences of service providers (i.e.

potential referral receivers) to receive referral requests and the

capabilities of the systems and services available to the referral

sender.

o Launching the Referral Manager that is associated with a referral

request template that is mutually supported by both the Referral

Sender system and Referral Receiver system.

1.3.3 Out of scope

The following are explicitly excluded from the scope of this document:

The processes of designing, creating, distributing, updating and retiring

eForms definitions.

The logical content specifications for the eForms, CDA documents and FHIR

resources which may be used in referral requests.

Activities that result in a “decision to refer” the consumer to receive a

specific type of health or human service.

Appointment scheduling.

Interactions with systems that manage claims and payments.

nehta


2 Enterprise viewpoint

2.1 eForms community

2.1.1 Overview.

The “eForms community” is a conceptual community of organisations whose

behaviour results in the ability for referral senders to create referral requests for

which the format and content may be determined based on the advertised

capabilities of the referral receiver.

This community was introduced so that this behaviour can be specified in isolation

of the other functions also performed by these systems. Other communities,

specified in other documents, address other aspects of system behaviour – for

example, the use of directories and workflow coordination.

2.1.2 Community objectives

The shared objectives of the participants in the eForms community are – though

adherence to a set of mutually agreed behaviours – to:

1 Enable different referral receivers to request that the information provided to

them in referral requests is to conform to specific referral request templates

(specifying format and content).

2 Allow the use of eForms as one means of allowing changes to be made to the

set of information in referral requests that is captured in a machine readable

from (and which is semantically defined by reference to standard information

models and terminologies) without necessarily changing deployed software

systems.



3 Computational Viewpoint

3.1 Introduction

This viewpoint describes a set of system roles that interact with each other in

defined ways to achieve the community objectives described in section 2.

3.2 Design constraints

In addition to supporting the agreed business requirements, the following design

constraints apply:

1 The systems that implement the referral sender and referral receiver system

roles may be at different levels of maturity with respect to use of eForms for

referrals.

2 A referral receiver may support multiple channels for receiving referral requests

including paper-based referrals such as letters that are mailed, hand delivered

or faxed, and electronic referrals such as HL7 v2 REF messages, CDA

documents and eForms that are delivered over proprietary or standards-based

secure messaging interfaces or by other REST or SOAP interfaces.

3 A referral sender must be informed, before they create an electronic referral,

whether or not it is possible for their chosen referral receiver to accept that

type of electronic referral. That is, the format, content and any services used

by the referral receiver and referral sender must be compatible. If they are not

compatible then the referral sender must be able to fall-back to another

supported referral channel (e.g. a paper referral) without disrupting their

workflow.

4 The use of eForms for referrals is already established – existing services that

use them must be supported.

3.3 Design

The logical system architecture is illustrated in Figure 1 and is described in sections

0 to 3.3.8.

Sections 0 to 3.3.8 are not intended to overly constrain implementers – rather they

are intended to provide context for the logical specifications that are included

3.3.1 Approach

The design approach that was adopted is one in which existing commercial

electronic referral services can be used without the need for significant software

changes.

In line with this approach, this document only singles out a limited set of interfaces

as being of a high priority for the development of new open interface standards. In

particular, this document only singles out one such interface.

Over time consensus may emerge for standardising more of the interfaces that are

identified in this document – doing so should result in referral senders and referral

receivers having even greater flexibility to independently choose the software

products and services that they use for electronic referrals. Standardisation of all

nehta


the interfaces identified in this document is therefore seen as a desirable future

state. However, at least in the short term, stakeholders will be in a transition

period. During this transition period organisations that procure electronic referral

solutions may seek to accelerate the standardisation process. This document is

therefore a living document that will evolve to reflect this on-going process of

standardisation.

3.3.2 Design overview

Figure 1: Referral sender system logical component model

The rectangles in Figure 1 represent “system roles” where a system role provides

an abstract view of a type of software component that is independent of

implementation and deployment choices. Neither system roles nor instances of

system roles represent deployed software components. In some cases an instance

Provider Selection

eForms Server

Referral Manager

External Services

Directory

Local Directory

Referral Sender System

Referral UI

User

Referral Management

Consumer Management System (CMS)

Resource Access

Document Management

CMS adapter

Action Execution

Referral Manager Registration

Lifecycle Management

Document Delivery

Status Delivery

Status Query

A system role for which there may be multiple instances

associated with any one referral sender

system

Legend

A system role which will typically only have one instance

associated with any one referral sender

system

Interface provided by component

Interface invoked by component

Dependency relationship

launch

Those interfaces considered to be of high priority for

standardisation are shown in red

eForms Distribution



of one system role may be implemented as a distributed set of software

components including a mix of locally hosted and cloud hosted components.

The purpose in denoting some of the system roles in Figure 1 as possibly being

implemented by multiple software components within a single Referral Sender

System is to reflect the fact that the relevant interfaces are not expected to be

standardised in the short term – if they were then a single implementation in any

given Referral Sender system of each role would be all that was required.

Note that the Referral UI is not included in the set of components for which multiple

instances are expected to exist within the same Referral Sender System. Rather it

is expected that the Referral UI will be implemented as a HTML5 browser whose

content is dynamically provided by the Referral Manager which was selected

(indirectly) by the user of the Local Directory as described in section 3.3.6. The use

of a HTML5 browser is not, however, a mandatory feature of the logical component

model. There may be multiple instances of the Referral UI within the same Referral

Sender System provided that the workflow for creating a referral request still starts

with the choice of referral receiver. This choice then determines which referral

request template to use and therefore which Referral Manager (and therefore which

graphical user interface) to use.

3.3.3 Security

This document does not address security in any detail, any implementation is

expected to apply the standards, tools, and guides of the National eHealth Security

and Access Framework (NESAF) in order to protect consumer data.

The Referral Sender System shown in Figure 1 represents a single logical security

context. That is, a user who is fulfilling the role of “referral sender” authenticates

themselves to the Referral Sender System and, as a consequence, they are also

authenticated to all the components that fulfil any of the roles that comprise the

Referral Sender System – i.e. Local Directory, Referral UI, Referral Manager, CMS

Adapter and CMS. Once a user is authenticated to the Referral Sender System their

authorisations are also determined for all its constituent components. As a

consequence the following apply:

1 The security context is not an explicit parameter to any of the logical interfaces

between components of the same Referral Sender System.

2 Trust relationships exist between the components of a single Referral Sender

System.

3.3.4 Referral Manager

3.3.4.1 Overview

An instance of the Referral Manager system role (simply termed a “Referral

Manager”) is integrated with an instance of the Referral Sender System role

(termed a “Referral Sender System”) in order to extend its ability to manage

electronic referrals.

As shown in Figure 1 there may be many Referral Managers integrated with a single

Referral Sender System. Multiple Referral Managers may be required by a single

Referral Sender System because:

nehta


Different providers of referral services currently use different technologies

to represent eForms, different interfaces to distribute eForms, different

interfaces to interact with the CMS and different interfaces to initiate and

manage referral processes.

Even if, in the future, all providers of referral services were to adopt

national standards for all these, using different Referral Managers to

manage different types of referral request will reduce the cost of

implementing the changes to business requirements and changes in the

adopted technologies that will inevitably occur over time.

3.3.4.2 eForms Distribution interface

A Referral Manager may include an “eForms Engine” that loads eForms definitions

from an external eForms Server. In this case it will be an invoker of the eForms

Distribution interface provided by an eForms Server.

However, not all Referral Managers will need to dynamically load eForms

definitions. Examples of cases where integration with an external eForms Server is

not required include:

Where the required eForm definition is hardcoded by the Referral Manager.

Where eForms are stored locally in the Referral Sender System.

This document does not include a specification for the eForms Distribution interface.

3.3.4.3 Referral Manager Registration interface

A Referral Manager is made available within a Referral Sender System though a

registration process. This is achieved by invoking the Referral Manager Registration

interface provided by the Local Directory.

As part of this registration process, a Referral Manager is associated with one or

more “filter expressions”.

A “filter expression” is an expression that takes as input any ELS interaction record

and returns as output the value TRUE or FALSE.

Filter expressions provide the mechanism for the Local Directory to match up the

types of referral that a referral receiver can accept with the types of referral that a

referral sender can produce. That is, if a filter expression evaluates to TRUE for any

ELS interaction record then the associated Referral Manager can be used to refer to

the organisation which is identified as the target in that ELS interaction record.

It is expected that one Referral Manager, which implements a “letter writer”, will be

registered with every Referral Sender System and will therefore be available as a

fall-back when no electronic referral is possible.

A Referral Manager may support only one “type of referral” (more formally one

“referral request template”). For example, a Referral Manager may create all its

referral requests as instances of the same CDA document type.

A Referral Manager may alternatively support multiple referral request templates.

For example, a Referral Manager may allow for different eForms to be used for

different types of service.

In order that Referral Managers can be provided by 3rd parties (e.g. referral service

providers) and integrated into any Referral Sender System, this interface should be



standardised as a high priority. The logical specification of this interface is therefore

provided in section 3.4.

3.3.4.4 Consumer Management System interfaces

A Referral Manager requires the Consumer Management Systems (CMS) to:

1 Provide data to auto-populate referral request fields wherever possible.

2 Store and retrieve the referral requests generated by a Referral Manager (and

other documents exchanged with the referral receiver).

3 Allow the Referral Manager to interact with the workflow management

capabilities of the CMS, for example, in order to post reminders and

notifications for the CMS user.

This document does not include a specification for the CMS interfaces. Section

3.3.5 does, however, sketch out a set of strawman interfaces that meet the

requirements listed above.

3.3.4.5 Referral Management interface

A Referral Manager serves content to and receives content from the Referral UI via

the Referral Management interface.

This document does not include a specification for the Referral Management

interface. The expectation is, however, that this interface will typically be

implemented as a web application and the Referral UI will be implemented using a

HTML5 capable browser.

The information provided to the Referral Manager to initiate a new referral request

will include the ELS Interaction Record which the Local Directory used to match the

filter expression associated with the Referral Manager. The logical information flow

for a new referral request is illustrated in Figure 2.

Figure 2: Information flows for a new referral request

Provider Selection Referral

ManagerLocal

Directory Referral UI

Referral Management

1 2

Step 1 – the user selects a service provider and a referral request channel and the Referral UI is provided with the corresponding ELS interaction record and the URL of the Referral Manager

Step 2 – The Referral UI provides the ELS interaction record to the Referral Manager to initiate the task of creating the referral request

nehta


After the Referral management interface is invoked (as outlined in Figure 2) the

Referral Manager either:

1 Presents the user of the Referral UI with the graphical user interface elements

necessary for entering the data required to create the referral request, or

2 Presents the user of the Referral UI with the graphical user interface elements

necessary for selecting an eForm and then for entering the data required to

create the referral request.

The first case applies when the ELS interaction record provided by the Local

Directory to the Referral Manager fully defines the referral request template to use.

The second case applies when the ELS interaction record provided by the Local

Directory to the Referral Manager does not fully define the referral request template

to use. This pattern may be common where an organisation provides all its

“referrable” services via a referral gateway that also acts as its eForms Server.

The user actions required to complete, verify, sign and submit the referral request

are not addressed in this document.

3.3.4.6 Workflow coordination interfaces

As shown in Figure 1, a Referral Manager, as well as being responsible for creating

referral requests, is also responsible for managing the lifecycle of referral processes

and tracking their progress.

This behaviour is defined in Cross-organisation workflow coordination [WFC] – in

summary a Referral Manager provides the Referral Document Delivery and Referral

Status Delivery interfaces and invokes the Referral Lifecycle Management and

Referral Status Query interfaces.

3.3.5 CMS Adapter

A CMS Adapter provides an interface to the CMS that is suitable for use by one or

more of the Referral Managers.

Three strawman CMS interfaces are proposed to support the requirements of

Referral Managers, these are:

Resource Access – this read-only interface provides the ability for a

Referral Manager to request the values stored by the CMS for a selected

set of resources. This interface is used to auto-populate fields in a referral

request.

Document Management – this read-write interface provides the ability to

store and retrieve documents relevant to referrals.

Action execution - this read-write interface provides the ability for the

Referral Manager to interact with the workflow management capabilities of

the CMS. This could be used to request the CMS to notify users of

important events, set reminders, etc.

This document does not include specifications for these interfaces but CMS adapters

are currently available that provide some or all of the required capabilities. Some of

these adapters use “open” interfaces and some use proprietary interfaces.

The open interfaces are:



Aduro interface5 - this is explicitly designed to support the use of eForms.

It supports all three strawman CMS interfaces listed above and adapters

are available for the leading GP products.

Hiasobi FHIR interface to GP systems6 - this provides read-only access to

CMS data and could therefore be used as the Resource Access strawman

interface – additional interfaces to the CMS would be required for the

Document Management and Action Execution strawman interfaces.

The Aduro and Hiasobi interfaces are each associated with their own specification of

the content that can be extracted from a CMS. In the case of the Aduro

specification, the content specification is termed the “data concept” dictionary - but

this is not currently part of the publically available specification. In the case of the

Hiasobi interface, the content specifications are the relevant publically available

FHIR resources. To the extent that these content specifications reference the same

concepts that are modelled in the Service Referral Structured SCS they represent

two different technical service specifications (TSS) that correspond to the same

canonical logical service specification (LSS) – i.e. the Service Referral SCS. The

alignment of these specifications has not yet, however, been determined.

3.3.6 Local Directory

3.3.6.1 Overview

The Local Directory system role extends the functions provided by the existing local

address books and directories which are currently used for referrals.

The Local Directory is key to supporting the desired workflow for creating and

sending electronic referrals in an environment in which the referral senders and

receivers may not use compatible electronic referral software and services. In these

cases the referral sender may need to fall-back to paper based referrals and, if they

do, they need to do so at the start of the process. The alternative, in which they

start by selecting a referral request channel that later turns out not to be supported

by their intended referral receiver, will unreasonably disrupt their workflow.

3.3.6.2 Service Directory interfaces

The interfaces provided by the External Services Directory are described in the

document Directory Integration [DI]. These interfaces may be invoked by a Local

Directory in order for it to maintain a local directory in synchronisation an external

Service Directory.

3.3.6.3 Provider Selection interface

A Local Directory serves content to and receives content from the Referral UI via

the Provider Selection interface.

This document does not include a specification for the Provider Selector interface.

The expectation is, however, that this interface will typically be implemented as a

web application and the Referral UI will be implemented using a HTML5 capable

browser.

5 See http://www.aduroalliance.com 6 See http://oridashi.com.au/site/hiasobi.html

nehta


The Local Directory supports the ability for users of the Referral UI to search for

service providers that accept referrals. Based on the ELS interaction records for

these service providers, the Local Directory lists the “referral request channels” that

are supported by these service providers.

A “referral request channel” is available to be used by the Referral Sender System if

the ELS interaction record matches a filter expression of a registered Referral

Manager. In these cases, the Local Directory presents a hyperlink for the user of

the Referral UI to launch the user interface provided by that Referral Manager.

If a “referral request channel” is not available to be used by the Referral Sender

System the Local Directory may “grey-out” that channel and may provide

instructions on how to obtain the necessary Referral Manager. There are significant

security risks for the referral sender in loading a new Referral Manager (or any

other component) into the secure security zone represented by the boundaries of

the Referral Sender System. Loading a new Referral Manager would therefore be

typically managed as an IT service management function (within an appropriate

configuration management framework) rather than as a user function.

3.3.6.4 Referral Manager Registration Interface

The Referral Manager Registration interface is provided by a Local Directory so that

Referral Managers can make themselves available within a Referral Sender System

A logical specification for the Referral Manager Registration is provided in this

document in section 3.4.

3.3.7 Referral UI

The Referral UI is a client of both the Local Directory and the Referral Management

interfaces. The expectation is that these interfaces will be typically provided as web

applications and the Referral UI will be implemented using a HTML5 capable

browser.

3.3.8 Consumer Management System

The functions of a CMS that are relevant to the proposed high-level eForms

architecture are outlined in section 3.3.5.



3.4 Logical interface specification

3.4.1 Referral Manager Registration interface

3.4.1.1 Purpose

The Referral Manager Registration interface is provided by a Local Directory in order

to allow for multiple Referral Managers to be available within the same Referral

Sender system.

3.4.1.2 Signature

Figure 3 Referral manager registration

The parameters of the register operation are defined in Table 1.

Table 1: register parameters

Parameter Obligation Cardinality Data type Description

referralManagerId Mandatory 1..1 UUID Uniquely

identifies a

particular

Referral

Manager

location Mandatory 1..1 URL The URL of the

Resource

Manager

filterList Mandatory 1..1 ELSFilterList An array of 1 or more ELSFilters -

see

Table 2

«interface»ReferralManagerRegistration

{abstract}

+ register(referralManagerId: UUID, location: URL, filterList: ELSFilterList): RegistrationResponse+ deregister(referralManagerId: UUID): DeregistrationResponse

nehta


Table 2: ELSFilter

Parameter Obligation Cardinality Data type Description

channelDescription Mandatory 1..1 String A textual

description of

the channel for

receiving

referrals that

this ELSFilter

represents.

target Optional 0..1 Qualified

Identifier

(see AS 5552 -

2013

See ATS 5546-

2013

serviceCategory Optional 0..1 URI constant See ATS 5546-

2013

serviceInterface Optional 0..1 URI constant See ATS 5546-

2013

serviceEndpoint Optional 0..1 xsd:anyURI See ATS 5546-

2013

serviceProvider Optional 0..1 Qualified

Identifier

(see AS 5552 –

2013)

See ATS 5546-

2013

3.4.1.3 Behaviour

The register operation associates the Referral Manager with a Local Directory.

The filterList parameter is a list of one or more ELSFilters. Each ELSFilter

consists of a mandatory textual description field (channelDescription) and a set

of optional fields.

An ELSFilter matches an ELS entry if, for every optional field that is included in

the ELSFilter, the corresponding ELS field has an equivalent value. Note that the

equivalence of fields of type “URI” shall be determined in accordance with ATS

5546-2013 clause 3.3.

When listing a potential referral receiver, The Local Directory provides a mechanism

(e.g. a hyperlink) for the user of the Referral UI to launch the user interface

presented by any of the Referral Managers for which one ELSFilter matches one

of the ELS interaction records for that referral receiver. If more than one ELSFilter

matches one of the ELS records then the user shall select their preferred choice –

the Local Directory shall enable the user to make their choice by displaying the

channelDescription associated with the ELSFilter.



More than one Referral Manager can be registered with the same ELSFilter.

The deregister operation removes the registration of the Referral Manager

which was previously registered with a value of referralManagerId that matches

that of the referralManagerId parameter to the deregister operation.

The ELSFilterList or the location of a Referral Manager can be changed by

deregistering the Referral Manager and then re-registering it with the changed

parameters.

nehta


Glossary

Term Meaning

CDA® Clinical Document Architecture

CMS Consumer Management System

ELS Endpoint Location Service

eForm An eForm is any electronic form that can be filled out without being

printed. This therefore includes everything from word processor

“templates” to “smart forms” which enforce field and cross-field

validation rules and can include externally sourced data at runtime

FHIR® Fast Healthcare Interoperability Resources

HTML5 Hypertext Markup Language version 5

Referral request template A referral request template is a specification of the set of elements (e.g.

eForms, CDA documents, FHIR resources, etc.) that constitute a valid

referral request



References

[ATS5546] Standards Australia, E-Health endpoint location service, 2013

[AS5550] Standards Australia, E-Health web services profiles, 2013

[AS5551] Standards Australia, E-Health XML secured payload profiles, 2013

[AS5552] Standards Australia, E-Health secure message delivery, 2013

[DI] NEHTA, Service Referral Reference Architecture – Directory Integration v1.0, March 2016

[eREF] NEHTA, eReferral v1.4.1, EP-1747:2014

[ODP] P. Linington, Z. Milosevic, A. Tanaka, A Vallecillo, Building Enterprise Systems with ODP,

pp 34, CRC Press, 2012

[SRSCS] NEHTA, Service Referral Structured Content Specification v1.0, March 2016

[WFC] NEHTA, Service Referral Reference Architecture - Cross-organisation workflow

coordination v1.0, March 2016

eforms and templates - health.vic/media/health/files... · eforms and templates 30 march 2016...

Documents