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 codes into 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”