HL7 Meeting: Use of CDA in a UK Context

HL7 meeting: Use of CDA in a UK context

Comfort Inn, Kensington

6 December 2005, 1pm

Long term objective: CDA convergence / interoperability with other standards.

Agenda

Requirements:

1. The need for a ‘stepping stone’ from GP Summary (text) to ACRS.
2. Message level semantics -> statement level
3. Framework for sharing information, e.g. SAP/NSF
4. Legacy/existing systems with no / limited messaging capability
5. A path to put a CDA message into a CfH clinical statement
6. CfH’s take on where CDA stands.

DM: hybrid approach to support text and structured data (as supported by CDA release 2) – text first; structured later.

iSOFT: in favour of text+coding. Non-coded statements in PSIS remove a barrier to CfH integration. Progression is sensible – but how does this map to emerging clinical statement?

CDA incorporates the Clinical Statement.

CDA group do not talk about CDA ‘message’. Clinical statement pattern is about achieving structural convergence. We have ways of transferring uncoded information; but CDA provides a document-based model.

Is messaging / document paradigm a semantic issue? Perhaps, but CDA assumes document management capabilities, and many systems (e.g. the majority of primary care systems) do not support this.

DM: One reason to discuss CDA is to ‘pool’ data into a document architecture – but this is compatible with the Clinical Statement; the main difference is the header

It was asserted that we don’t have a way (except bespoke / v2) of sharing all types of clinical information in v3. Most immediate use case is that CfH will not provide messages to carry all necessary information – and CDA could mitigate this.

DN: Suggested that Implementation guidance is needed, and this would be as much the case of CDA as for PoC messages (and indeed for V2/bespoke).

AP: If introducing text blocks into messages, why not use CDA? If a very generic message is required for Provision of Care,

CMcC: 2 types of use case: structured text with a migration path to clinical statement; or ‘just send text to get into a patient record’ in a v3-friendly way.

MS: CDA – text is authenticated. Clinical Statement: coding is authenticated and text should only be used to carry information that cannot be coded. DM: no – CDA is fine for communicating text, but the motivation should be clear and complement the current v3 thinking on semantics.

If requirement is JUST to send text, use message or CDA. Where requirement is text and coded information, this is a separate problem.

MS: The coding shortfall creates the use case here.

DM: Getting rid of text altogether is unfeasible, but encouraging people to transfer text will undermine CfH. CDA has nothing to do with coding; the issues are:

1. Document or message paradigm?
2. How much of the information is coded
3. The relationship between text and code where both are being sent

What goes into the implementation guides? What is displayed to the user before it is sent? How is the text derived? When many CDA documents about one patient, how much of the duplicate information should be displayed to the user? Document vs. message paradigm is primarily about storage and retrieval and rendering.

GJ: CDA is convenient because the same diagnosis can be referenced and repeated in multiple documents: ACRS makes it more difficult to establish.

The clinicians job is: what is the status of the patient today?

HG: we might want to think about CDA:

1. Because CfH has moved towards this ‘text’ structure, we are interested in CDA. Depends on CfH acceptance of CDA. [how should CfH present document level semantics]
2. In other types of messages between other players, it might be easier to keep information partially coded, and implementation might be easier if a document standard were established. This is down to suppliers and users, independently of CfH [how should local issues be solved]

Reasons for choosing CDA over another technology is another question.

Also transport / security issues.

NR-M: As an implementor, CDA is a new burden.

DM: CDA references are part of the document, not the information. CDA is designed to be a human-readable document – CDA spec suggests MIME-encoding. Persistent; stewardship; potential for authentication; human readability.

All: Discussion about CDA regards a document-based architecture.

Two different use cases: one is where ther is access a repository of clinical statements, the other use case is to pass a logical entity to a system which does not have access to the repository of clinical statements (without changing meaning / context etc).

MS: We carry clinical information in a way that can be interpreted as isolated entities – and this contradicts their transfer as part of the clinical statement.

NB: we are talking about text and coded data; does the authentication have to apply to both in parallel? Where is the linking between text and codes? DM: Any new rendering is a new CDA document with an authentication requirement.

Text - codes vs codes - text transcription.

TC: research use case: interested in data being used for clinical research through feeds of structured, coded data. DM, MS: this is what the messages are for; CDA will not deliver this requirement.

MT: CDA is not intended as a coded document; it is a clinical statement, and there should be no enforcement of the links between text and data. DM: yes – the safest way for the text to be a ‘poor man’s fallback’ for those who cannot read the codes.

MR: Then what is the business case for another communication paradigm? V3 can carry a block of text. GJ: CDA is v3-based, but is not a messaging paradigm.

GJ: advantage is that CDA doesn’t require prior knowledge of clinical information conveyed in receiving system.

DM: Do we need to talk about the way that structured text should be conveyed in the NHS? So should text be conveyed as a narrative block or CDA?

DN: clear business case for a document paradigm alongside messages, provided any extracted data fragments are communicated with the originating document.

CDA has many uses in terms of current processes because they currently represent a document paradigm. DM: build-up of documents which include re-statement of previous clinical information creates a context problem. The CfH Clinical Statement provides a statement identifier to express context / identity. CDA creates a new context; good for pulling together and publishing a summary but not good for communicating data. Clinical Statement is explicitly separable.

CDA attributes:

1. Communication of structured text
2. Communication of structured text + codes
3. Document paradigm (CDA header) – rationale for CDA over messages is:
4. It is a normative standard
5. In order to make use of the CDA header

CMcC: Is there a use case for the CDA header (stewardship)? Metadata and provenance is important – a document paradigm requires a header.

1. Use cases for document paradigm over messaging paradigm
2. Further investigation of structured text alongside codes
3. Transport / security

1. Things that are naturally documented – use CDA?
2. how to handle structured codes

USE CASES / REQUIREMENTS

(problem space – what can we not currently do with v3?)

ACRS involves the implementation of many CRE types throughout application – wouldn’t this be easier if the text already in my application could be migrated into CREs?

Text

Text+CRE

Text+CRE+codes

SAP / discharge letter use cases:

1. Sending clinical information to a system which is not Spine-compliant and does not talk Provision of Care.
2. Rendering clinical information – simple implementation option (facilitate migration)
3. Test result – coded and renderable
4. Intermittent connection
5. Business need for transfer of information outside the CfH domain
6. Collating data pulled from multiple sources and publishing as a group (publication makes the document)

Potential approaches:

1/6. variants of CfH messages

6. Publishing makes a document, so data needs to be shared even when the multiple systems are not available. Certainly not possible to keep within the borders of an LSP. Even if data does not cross LSP boundaries, document requirement will.

CMcC proposes: long term, HL7 proposes the use of particular artefacts for each use case (whether v2, CDA or whatever)

DM: if we use CDA where there is a use-case for a document paradigm, ensure same constraints apply as message model. If we come up with an approach to the structured information (for supporting participant information plus consistent support as text information), we can endorse this as an HL7 / UK constraint on how data is represented. So:

Workstreams:

1. Clinical content consistent across CDA and other messages: so we have a standard for the representation of text – a workstream in itself. How do you use clinical statements in PoC in the same way that they are used in CDA? [DM: And how consistent does the clinical content have to be?]

Action:AP to express this principle for HL7.

1. Non-CfH specifications, with reference to MIM and HL7.org

MS: two current models:

a) Use a constrained version of the US model

b) HL7 design principles and mirror the MIM

Action:HG to convene forum at next HL7 UK TC for suppliers / CfH to discuss requirement. HG to collate use cases and discuss as a new thread (CM can assist with reference to diabetic eye disease; GJ will also produce use cases in terms of drilling down to local systems; MS will discuss local integration of pathology systems; TC will provide use-case of endoscopy). All to post use cases back to Hugh Glover.

Pressing requirement for CfH: similar messaging outside a CfH context, which should happen collaboratively, through HL7 UK, to identify extra functionality / additional modelling required.

Action: RS to take this back to CfH

1. Normative markup: XHTML, CDA, ... (for next TC meeting)? [Clinical Statement as represented in the MIM is heading towards a similar status (as a standard) as the current worldwide normative CDA standard]

Action:Dave Nurse (delegate) + JL to convene discussions around this.

1. Document paradigm when something is to be published and shared

Action: DN and JL to convene discussions around this.

ISSUES

Convergence issue: CfH Clinical Statement / CDA statements

Document / message paradigm

Narrative block vs. structured codes

Is CDA any easier than the message detail?

Document progression (duplicate items)