HL7 development in 2007/8

Rik Smithies

Chair HL7 UK

NProgram Ltd, CFH

HL7 development

Clinical Statement

• Reached DSTU, Sept 2007

• The model for structured (coded) clinical data in HL7

• Actually been more or less constant for some time.

HL7 development

Clinical Statement / CDA

• Started life in GP2GP project, pre-NPfIT

• Now part of the foundation for CDA– Success of CDA partly that CS part optional– But there for the full structure when needed– CDA is V3, not an easy alternative, it’s easy

V3.

HL7 development

(Digression into) CDA• Unlike rest of V3 you don’t create a message

design with CDA• CDA is the message, pre-built• No tooling necessary, no need to deeply

understand V3 modelling from scratch.• You specialise CDA how you like, with written

documents if required. – “Use this code in this section, don’t use that section”

HL7 development

CDA• You can also ‘constrain’ with V3 modelling

(CFH method)• In practice you will probably want some

machine processable constraints to narrow down CDA use.

• Generated schemas, generated schematrons, or hand made schematrons.

HL7 development

Templates• Also passed DSTU September 2007• Typically used on top of CDA

– Adds rigour and specialisation for local needs

• Small patterns of data used to tighten another model• Can be diagrams (V3 RIM models)• Can be text in a paper document – zero bar to entry.• But must be valid additional statements about V3 model

– “Don’t use this class of the standard CDA”– “This part of the message must use code X even though CDA

allows any code here”

HL7 development

Templates

• been around almost as long as Clinical Statement

• Much confusion as to what they were

• Various apparently different techniques

• Realised that technique not the key– but the fact of an additional constraint on an

underlying model, however expressed

HL7 development

Templates

• Much UK and HL7 UK input to the specification– especially on the diagram based constraint

style– CFH tooling to support this approach– Other tooling exists to convert “structured

english assertions” to machine checkable rules.

HL7 development

TermInfo

• Third part to get DSTU in Sept 2007• Means “Terminology Model/Information

Model”• How to fit a terminology model

specifically SNOMED codesinto an Information Model

namely HL7.

HL7 development

TermInfo

• “codes” often duplicate things you can do with message models

• eg HL7 has slot for procedure method– SNOMED allows specifying method in the

code itself

• 2 ways to say the same thing– reinforcing? doubling? contradicting?

HL7 development

TermInfo• TermInfo lays down the rules for how

SNOMED and HL7 work together • CFH had adopted a pragmatic position

– early SNOMED adopter. • UK ideas drove TermInfo standard

– quite a bit of resistance– compromise won out

• CFH position compatible with outcome

HL7 development

Other changes:

• PA (Patient Admin)– Produced structure for UK style Registered

GP• after requirements raised by HL7 UK TC

• Tooling– CFH leading on tooling, update later.

HL7 development

Other changes:

• Datatypes V2, balloting now.– Set of building blocks (basic types)– UK input– Improved for UML tooling compatibility and to

harmonise with other standards.

• V2 – update later.

HL7 development

RIM Based Architecture• New thinking in HL7 • Started in the Netherlands

– Realised several production systems used V3 RIM as their internal model

– Unexpected since “V3 is just messaging, right?” ~ lore– But messages are clinical models in own right– RIM supports wide range of data for messaging– A RIM based system therefore supports a wide range

of medical data, in a single model

HL7 development

RIM Based Architecture• Meeting convened at January WGM• Existing HL7 Java group have similar code

– Parses, digests, stores, creates HL7 V3 messages– By understanding just the RIM– Running in live environment– RIM has rigour to support implementation– It works - not well publicised!

• Good validation of the RIM as a general purpose reference model– “It’s not just messaging”