Pathology – GP Order Comms
HL7 UK Technical Committee
9th December 2008
Paul Richardson
Project Background
Under the auspices of the Modernising Pathology
Programme, the Department of Health (DH) is currently
working in partnership with NHS Connecting for Health
(NHS CFH) and other key stakeholders to improve IT
connectivity between GP practices and pathology
laboratories.
Pathology Modernisation Agenda
• Carter Report
– Lord Carter of Coles was appointed to lead an
Independent Review of NHS pathology services in
September 2005. The Report of the Review of NHS
Pathology Services in England was first published in
August 2006.
– A key recommendation is that within pathology there
should be end-to-end IT connectivity and national
availability of order communications and decision
support, based on an agreed data set.
– Final report publication due ‘sometime’ 2008
Where are we now?
• PMIP - Pathology Messaging Implementation Project.
• Pathology messaging standards for information content,
structure, management and security of electronic
pathology report messaging between laboratories and
GPs
• Well established and in place since the late 1990’s
• Messaging standard originally delivered by X400 and
DTS since 2003
• Highly successful project which has achieved nearly
universal take-up.
Very high volume business
Around 700 million tests conducted in
England last year!
Around 40% of which were ordered by GPs.
PMIP – Limitations
• Offers only a limited electronic reporting service
– Only Clinical Biochemistry & Haematology receive fully
structured report messages
• Does not provide electronic requesting
• Uses an EDI legacy messaging standard which is not
understood by current strategic applications such as
the NHS Care Records Service
• Critically, relies on legacy DTS communications
infrastructure which is due to shut down in mid 2010
Benefits
•
Patients
– improved reliability of service – through fewer
inappropriate tests, fewer lost results, fewer
duplicated tests and less chance of the wrong
samples being taken;
– faster results – especially those that could not
previously be sent electronically;
– secure requests and results - knowing that
personal information can only be seen on a ‘need
to know’ basis by healthcare professionals
– improved patient choice – through more flexible
phlebotomy services.
Benefits
•
Pathology Laboratory Services
– Improved data quality
– reduction in the repetitive data entry of patient
demographics and sample details;
– faster and more efficient specimen reception as a
result of improved workload planning and receipt
of complete and accurate information;
– improved resource and manpower management
as a result of better workload planning;
– overall reduction in sample turnaround times with
faster results reporting;
– fewer enquiries and phone calls to the laboratory
from GP practices;
– fewer sample labeling errors.
Benefits
•
GP Practices
– help inform the practice about the appropriateness
of tests and the correct specimens to take;
– avoid handwriting requests and enable more
results to be received and filed electronically;
– assure automated filing of results into the patient
records;
– receive more results electronically including all
pathology disciplines;
– facilitate the introduction of decision support which
checks the relevance of the request, resulting in
fewer requests being rejected;
– help ensure results are available for when patient
appointments are made;
– printing of specimen labels.
Phase 1
“Establishing interoperability”
• Pathology test requesting for all disciplines using HL7v3
messaging
• Pathology test reporting
• Tests selected from the National Laboratory Medicine
catalogue
• Sending sample information to the lab following
phlebotomy
• Samples and requests must be marked with a common
request identifier
• Reporting on outstanding tests
• Support for screening programme status codes
• Support for Confidential tests
• Results of tests ordered by other parties copied to the
GP system
Phase 2
This phase introduces the following key functional
features:
• Lab-to-lab test referrals
• Test Request Templates as an aid to efficiency
and standardisation for GPs
• Some further coding in both requests and
reports, including the coding of microbiology
results
• Support for more unusual sampling scenarios
• Requesting tests directly from the HPA
Phase 3
This phase introduces the following key functional features:
• Choice of laboratory for GPs
• Sending reports to copy recipients
• Many more coded items in the request, including the
reason for the test, and the supporting information
• Coding of results in the report for all disciplines, including
mandatory coding for histology
• Cancellation of a test request by the requester
• Test status checks
• Clinician sealing
• Recording ‘refusals to seal’
Message interactions
• Phase 1
• Sub set of the HL7 Pathology ballot pack
• A number of message types in full set redundant due to
technical implications of the spine messaging ebXML and HL7
acknowledgements.
Message Interaction Name
Interaction ID
MiM Version
Order Fulfilment Request w/ RR
POLB_IN020001UK01
7.2.02
Order Confirm Response
POLB_IN020002UK01
7.2.02
Result In Progress w/RR
POLB_IN020005UK01
7.2.02
Result Complete w/RR
POLB_IN020006UK01
7.2.02
Application Acknowledgement
MCCI_IN010000UK13
7.2.02
• Phase 2
• Sample tracking
• messages currently under discussion with HL7 xxx
Order placement and confirmation
GP
Application /
MHS
Order message A
GP app
initiates
order
message.
Create
and send
message
Order message A
ebXML ack
ebXML ack
MCCI..13 HL7 ack to message A
MCCI..13 HL7 ack message A
ebXML ack
Message
validation
check
message
validation
check
Process
order and
store on
inbound
queue
confirm /
reject
message
initiation
Sample
received and
matched to
order
ebXML ack
Order Confirmation / rejection – msg B
GP app to
update
order id
Lab
Application /
MHS
TMS
Order Confirmation / rejection – msg B
ebXML ack
ebXML ack
MCCI..13 HL7 ack to message B
MCCI..13 HL7 ack message B
ebXML ack
ebXML ack
Retry to std contract
properties then:
Std msg queue
HAM
Results
Store
result
report
validate
HL7
message
and send
MCCI
response
Result msg Z
Result msg Z
ebXML ack
ebXML ack
MCCI..13 HL7 ack to message Z
GP
Application / MHS
MCCI..13 HL7 ack to message Z
ebXML ack
ebXML ack
report
complete
and
initiates
message to
GP system
Lab
Application / MHS
Retry to std contract
properties then:
Std msg queue
Slow retry for x hours
HAM
Send
result
message
Some technical challenges
• Service discovery
– Common point to point messaging issue
– Directory of service for point to point services
• Choosing the appropriate interaction style
• TMS message reliability services (HUM /
HAM)
• SNOMED-CT coding
Pathology Catalogue
The Pathology Catalogue consists of two components:
– National Laboratory Medicine Catalogue
• Nationally agreed content
• Coded reference file of tests
– Lab specific changes
• The lab “Handbook”
• Each lab can add their own additional attributes
• Each lab cuts down the national list to those tests
provided
• Can include rich content, including images, data
tables, documents, etc.
Pathology Catalogue – Content
Local Lab Catalogue & Handbook
Local subset
of tests
All national tests
National Catalogue
Rich decision support content
Locally agreed
Basic coded reference content
Nationally agreed
Pathology Catalogue – Hosting
National Catalogue
Local Lab Catalogue & Handbook
Hosted nationally
by TRUD
Hosted nationally by new web service,
with defined interface
NMAS
There is currently a test service that assures the
existing PMIP EDIFACT messages, the National
Messages Assurance Service (NMAS)
NMAS currently has 3 purposes:
1.Provide connection confirmations between
services
2.Message compliance checks
3.Clinical governance reporting
NMAS Replacement Requirements
A replacement for NMAS will be needed:
- to perform message compliance testing during
product and deployment testing
- to perform ongoing message compliance once
live
- to perform ongoing clinical governance reporting
NMAS Replacement Solution
The replacement solution involves:
- Using the OMVT2 toolset to run content
compliance testing on messages
- Using the “Spine in a box” to perform structural
and message interaction testing
- Ongoing compliance and clinical governance
testing to use similar scripts to OMVT2, but only
run on 1-in-n messages
NMAS Future
New NMAS solution could be expanded to support
other programmes in an ongoing message
assurance capability
Message refinements
The CfH pathology domain messages are a
significant refinement of the .org model, both in
terms of:
• the use of interactions
• message constraints
The design focus was to simplify in order to
support GP ordering with some consideration for
lab to lab ordering.
Message interactions
We’ve adopted a reduced set of interactions, e.g. no status
check interaction
We’ve simplified our approach to replacing reports. This
can only be performed at a ‘whole report’ level.
A difficult decision related to how to support sending
information relating to the sample collection process.
• We decided to send the request message again, with no
change from the original order except for the addition of the
sample collection information
Message design
•The usual UK modifications
– we have just relaxed the restrictions on the use of the NHS number
– Use of CfH vocabs
– SNOMED-CT
•A new report focal act was introduced – LaboratoryReport
•The CMET carrying the specimen related information was significantly
simplified resulting in ‘SpecimenLite’:
– It is designed to be used for general Laboratory requests and
reports without the overhead of the requirements of Automation
or Specimen Tracking. It is constrained for use with Human
subjects and excludes environmental, non-human and
manufactured specimens.
•Numerous other changes
•All valid constraints
Message documentation
•Very substantially revised tabular text
•Many XML examples – chosen to demonstrate the use of all significant
message feature
•Using the IM page to specify message patterns and construction
principles for requests and reports
•About to embark on a refresh of some of the earlier business analysis
artefacts
CfH Comms and Messaging have said that because of the attention to
detail that we’ve applied to the documentation and the prototyping and
consultation process, they believe that the Pathology domain will be the
easiest to support. They typically are used to floods of queries from
suppliers asking for clarification and guidance.
Requirements development
process
By “requirements” I mean functional and non-functional requirements
and the MIM.
1.
Write initial set (publish in MIM as draft)
2.
Consult internally
3.
Refine
4.
Consult selected vendors and users
5.
Refine
6.
Develop example XML messages
7.
Develop assurance tools and scripts
8.
Develop prototype with selected vendors and users
9.
Assure prototype messages
10. Refine requirements and specifications
11. Publish as normative
Future uses of the message set
The GP order comms project establishes a set of standards for
pathology order comms in England.
The lab will be able to accept requests from many other settings such
as prisons, care homes, community care and the acute sector.
Population screening services could also use the message set, e.g.
•
Newborn blood spot screening results sent from screening labs to
child health systems
•
Bowel cancer results sent from the screening labs to GP systems