What is PITO? - e-Health Conference
Download
Report
Transcript What is PITO? - e-Health Conference
Accelerating Change
The PITO EMR-to-EMR Data Transfer & Conversion
Specification (E2E-DTC):
Experiences in Developing and Piloting A
Consolidated CDA Specification
May 28, 2013
Ottawa
Carol Rimmer
Marc Koehn
BC Physician Information
Technology Office
Gordon Point Informatics Ltd.
Image Source:www.quitehealthy.com
DISCLOSURES
2013-May-28
PITO & GPi
2
Faculty/Presenter Disclosure
• Faculty: Marc Koehn
• Faculty: Carol Rimmer
• Relationships with
commercial interests:
• Relationships with
commercial interests:
– Employee of Gordon Point
Informatics Ltd.
2013-May-28
– Employee of BC Medical
Association, Physician
Information Technology
Office
PITO & GPi
3
Disclosure of Commercial Support
• This program has received financial support from The BC Medical
Association and the Government of BC in the form of direct project
funding through the PITO office.
• Potential for conflict(s) of interest:
– Gordon Point Informatics Ltd. developed and has leveraged a software tool to
produce Consolidated CDA Guides mentioned in this presentation.
2013-May-28
PITO & GPi
4
Mitigating Potential Bias
• The proprietary software tool is not the focus of the
presentation; other tools will be noted.
2013-May-28
PITO & GPi
5
Outline
•
•
•
•
•
What is PITO?
Why this project?
What did we do?
What is the result?
What’s next?
2013-May-28
PITO & GPi
6
WHAT IS PITO?
2013-May-28
PITO & GPi
7
What is PITO?
• Set up by the BC Medical Association (BCMA) and the BC government as
part of their 2006 agreement. Currently have a mandate to March 2014.
• PITO’s primary responsibility is to support the adoption and use of
electronic medical records (EMRs) in physicians’ offices across BC.
• PITO assists physicians during pre-implementation planning,
implementation, and post-implementation, and coordinates the
disbursement of IT funds to physicians as defined in the agreement.
2013-May-28
PITO & GPi
8
What is PITO?
• PITO has four primary goals:
Adoption
Capacity
Solutions
Impact
• Post-Implementation support is focused on achievement of meaningful
use.
2013-May-28
PITO & GPi
9
What is PITO?
On EMR
Not on EMR
Target
Not on EMR
Non Target
GPs
2660
649
SPs
1380
Total
4040
Total Target
Physicians
Total
Not
Eligible
Grand
Total
844
4153
1500
5653
435
840
2655
2534
5189
1084
1684
6808
4034
10824
5124
5024 Target Physicians
79% On EMR
6808 Eligible Physicians
59% On EMR
*Excludes WIC, Psychiatry, and MDs
within 2 years of retirement
*Excludes inpatient, pathology, radiology, locum,
hospitalist, and retired physicians
• Visit http://www.pito.bc.ca/ for more information
2013-May-28
PITO & GPi
10
EMR-to-EMR Data Transfer & Conversion Specification (E2E-DTC)
WHY THIS PROJECT?
2013-May-28
PITO & GPi
11
Why this Project?
• Locked Data = Barrier to Collaborative Care
– Gaps in EMR data standards as well as a general
lack of thorough vendor adoption risks locking
critical clinical data inside
EMR systems
– This continues to present
a barrier to effective clinical
collaboration as well as
EMR migration
2013-May-28
PITO & GPi
12
Why this Project?
• To address this issue, PITO sought the
development of a strategy to establish – by
adoption, adaptation or, if necessary,
development – a specification to support:
– Transfer of data when a physician changes from one
EMR system to another (“Conversion”);
– Transfer of data when a patient moves from one
family physician to another, or one long-term
specialist physician to another; e.g. a diabetic
transferring from one endocrinologist to another
(“Transfer”); and
– Transfer of data with a referral or consult request and
report, to populate or update the records of the
receiving physician (“eReferral”).
2013-May-28
PITO & GPi
13
Phase I – Environmental Scan: Options &
Recommendations
Phase II – Collaborative Specification Development
Phase III – Implementation: Pilots, Vendor Incentives, etc.
WHAT DID WE DO?
2013-May-28
PITO & GPi
14
Phase I – Environmental Scan:
Options & Recommendations
• Option analysis report
– Initially completed in Early 2011
/ Refreshed October 2011
• Environmental Scan
– Reviewed key specifications
•
•
•
•
•
•
•
Alberta's ToPD and CoPD specifications (collectively referred to as TCoPD);
Vancouver Island Health Authority's Electronic Medical Summary (e-MS);
The Data Portability Requirements (Appendix B) of OntarioMD's Clinical Management Systems (CMS)
Specification;
HL7's & ASTM International’s Continuity of Care Document (CCD) specifications; and
England’s National Health Service’s (NHS) GP-2-GP specification.
ASTM International was formerly known as the American Society for Testing and Materials (ASTM)
Other pan-Canadian Specifications including CIHI PHC and Infoway standards
– Other initiatives (e.g. BC Interior Health “EHR Integration – CCD Standard for Results
Distribution”)
– BC Vendor and Stakeholder dialogue
• Established key recommendations
– Various recommendations pertaining to collaboration and engagement
– Specific technical recommendations …
2013-May-28
PITO & GPi
15
Phase I – Environmental Scan:
Options & Recommendations
T/CoPD
2013-May-28
PITO & GPi
16
Phase I – Environmental Scan:
Options & Recommendations
• Key Take-Away Points
– Beg, borrow and steal … but make “incremental”
improvements
•
•
•
•
Take the best from other specs
Fix issues
Don’t invent things that don’t need inventing
Move forward
– Think “platform and foundation” … Focus on today
but build for the future
2013-May-28
PITO & GPi
17
Phase II – Collaborative Spec Development
• Rapid Timeline
– December 2011 – May 2012
• Full Collaboration
– Established Clinical and Vendor Stakeholder
Panels
– Reviewed requirements with stakeholders based
on specific subject areas
– Adjusted Specification Strategy to focus on
“document paradigm” – given practical advice
from conversion experts, stakeholders and other
key examples in the market place
2013-May-28
PITO & GPi
18
Phase II – Collaborative Spec Development
• Tooling and Development
– Briefly Assessed CDA tools including
• Trifolia WorkBench
• Model Driven Health Tools (MHDT) for CDA
• … but not … DECOR (Data Elements, Codes, OIDs and
Rules) Infrastructure
– Devised a prototype constraint tool for better
control over the model and the output
– Built Draft Specification using the tool
2013-May-28
PITO & GPi
19
Phase II – Collaborative Spec Development
• Key Take-Away Points
– Involve vendors / developers as early as possible
– Use tools to improve the “state of the art” of
building and publishing specifications
– Consider a framework, such as CDA, which has
adoption, market traction and – perhaps most
importantly – provides an on-ramp that positions
for “progressively deeper” data exchange over
time!
2013-May-28
PITO & GPi
20
Phase III – Implementation
• Initial Users
– UBC/UVIC Primary Care Informatics LEAD Lab –
also working with the BC Physician Data
Collaborative PDC
– Nanaimo Division of Family Practice eReferral Pilot
– Prince George eReferral Pilot
– … others …
2013-May-28
PITO & GPi
21
A Consolidated CDA Spec
to support a range of use cases
Positive developer feedback
WHAT IS THE RESULT?
2013-May-28
PITO & GPi
22
Key Outcomes to cover
• A “new” approach to CDA Development
• … with a fairly comprehensive clinical content
model.
• Constructive early feedback from developers
• … to allow change / improvement.
2013-May-28
PITO & GPi
23
Brief Detour – What is CDA …
•
The Clinical Document Architecture (CDA) is:
– a document markup standard for the structure and semantics of an exchanged "clinical
document".
– documentation of observations and other services.
•
•
•
•
A CDA document is a defined and complete information object that can exist
outside of a message, and can include text, images, sounds, and other multimedia
content.
CDA hits the “sweet spot” – CDA encompasses all of clinical documents. A single
standard for the entire EHR is too broad. Multiple standards and/or messages for
each EHR function may be difficult to implement. CDA is “just right”.
Implementation experience - CDA has been a normative standard since 2000, and
has been balloted through HL7's consensus process. CDA is widely implemented.
Gentle on-ramp to information exchange - CDA is straight-forward to implement,
and provides a mechanism for incremental semantic interoperability.
– Level 1 – Structured Header + Blob
– Level 2 – Structured Header + Sections
– Level 3 – Structured Header + Structured Sections
•
Improved patient care - CDA provides a mechanism for inserting evidence-based
medicine directly into the process of care (via templates), making it easier to do
the right thing.
Heavily abridged from HL7 Materials!
2013-May-28
PITO & GPi
24
A Use-Case-Driven, Canadian focused
Consolidated CDA Spec
•
Uses the HL7 Clinical Document Architecture
(CDA) template model
–
•
Adheres to the latest global best practice in the
structure and design of Clinical Document
Architecture (CDA) specifications
–
–
–
•
Leverages the style approach used by the IHE / HL7
Consolidated CDA guide emerging from the US
Health Story project
(http://www.healthstory.com/index.html)
Establishes explicit, testable conformance criteria.
See
http://www.hl7.org/implement/standards/product
_brief.cfm?product_id=258
Follows HL7 RIM to offer a degree of consistency
with pan-Canadian standards
–
•
Forces consistency across several “document”
specifications that are intended to support a variety
of uses cases including EMR-to-EMR conversion,
Patient Transfer, and other diverse data exchanges
via either a General Episodic Document or an
Unstructured Document (e.g. PDF).
Note that this is imperfect given compatibility
issues between CDA R2 and message based
specifications)
Tooling driven for precision, comprehensiveness,
and traceability!
2013-May-28
PITO & GPi
25
That is Tooling-Enabled …
• Precision
• Maintainability
• Presentation
Flexibility
Tooling
•
•
•
•
Guide structure
Templates
Constraints
RoseTree
Linked
Vocabulary
• Implementation
specific
Value Sets
• Etc.
2013-May-28
Text Segments
Fully Generated
IG Data
Formal
Structure
PITO & GPi
26
Section Templates
That covers a broad range of EMR content …
• Advance Directives [42348-3]
• Alerts
• Allergies & Intolerances - Reaction List
[48765-2]
• Appointments & Scheduling [56446-8]
• Billing
• Care Plan / Reminders / Tasks [56851-9]
• Clinically Measured Observations
• Current Medications
• Developmental Observations
• Devices [46264-8]
• Encounter History & Notes [46240-8]
• Family History [10157-6]
• Immunizations List [11369-6]
• Investigative Procedure History
• Laboratory Results & Reports
• Medical History [11348-0]
• Medical Imaging Results & Reports
• Medications & Prescriptions - Medication List
• Orders & Requests
• Problems & Conditions - Problem List
• Purpose
• Reproductive Observations
• Risk Factors [46467-7]
• Surgical Procedure History [10167-5]
• Treatment History
PITO & GPi
27
• Specific document
templates defined:
– EMR Conversion Document
– Patient Transfer Document
– Generic Episodic Document,
and
– Unstructured Document
• e.g. container for other
content such as PDF.
First two are targeted at the
respective use cases.
The last can be used to support
any process (e.g. eReferral).
• These document specs build
on a library of common
Section, Section Entry, Entry
and Data Type templates …
2013-May-28
… and tries to follow best practices of alignment
and precision …
• Header aligned with (but slightly expanded from) BC Interior
Health specification - a parallel project covering a different
set of use cases
• Consistently enumerated, testable Constraint Statements
against the formal CDA R2 model
• Explicit Vocabulary Bindings that leverage HL7,
Infoway/Standards Collaborative & (soon) PHC RefSets
through integration
• Purposeful use of formal conformance language while
retaining developer friendly tabular views
• Integrated XML examples
• Comprehensive cross-referencing and “hot links”
2013-May-28
PITO & GPi
28
Initial Learning
• LEAD Lab Feedback
– Pinpointed challenges to certain parts of the specification
– Many QA points but also some issues; key among these
was “Medication” model and gaps in various vocabulary
areas
– Billing data exchange is likely an unexpected gap
• Nanaimo Feedback
– Level 1 only … with minor changes identified to header
– Works … and is almost live in production!
• Other Realities
– The world has moved forward with the introduction of, for
example, PHC RefSets …
2013-May-28
PITO & GPi
29
WHAT’S NEXT?
2013-May-28
PITO & GPi
30
Next Steps?
• Specifications are available through PITO web site
– a Revision that addresses feedback from early
adopters and adds new terminology details will be
published shortly together with “test/sample”
documents
• Technical support mechanism for vendors has
been established
– additional funding for vendor implementation has
been established
• Initial projects are continuing and …
– There are currently 4-6 eReferral Pilots in the early
stages of implementation that will further leverage
and test the specifications
2013-May-28
PITO & GPi
31
Acknowledgements
• PITO Oversight
• Phase II Vendor Participants
– Jeremy Smith
– Carol Rimmer
– Rachel Barker (Intrahealth Canada
Limited)
– Shamir Mithani (Intrahealth
Canada Limited)
– Jack Pannekoek (Med Access Inc.)
– Toni Foster (Osler Systems)
– Sean Hillier (Wolf Medical Systems)
• Clinical Panel
–
–
–
–
–
–
–
–
–
Anita Basic
Dr. Rob Carruthers
Dr. Bill Clifford
Dr. Bruce Hobson
Cathy Korn
Trina Langille
Dr. Willie Pewarchuck
Dr. Andre du Toit
Dr. Andre de Wit
2013-May-28
• GPi Team
–
–
–
–
–
–
–
–
PITO & GPi
Marc Koehn
Helen Stevens
Iqbal Sian
Patrick Loyd
Dr. Karim Keshavjee
Dr. Ahmad Zbib
Dr. Ray Simkus
Bradley MacDonald
32
More Information?
Marc Koehn
Gordon Point Informatics Ltd.
[email protected]
+1-250-216-0803
gordon point informatics
www.gpinformatics.com
Carol Rimmer
BC Physician Information Technology Office
[email protected]
+1-604-638-5775
2013-May-28
PITO & GPi
33
Guide Examples
APPENDIX
2013-May-28
PITO & GPi
34
Specification Overview
Indicates the whether a
section SHALL, SHALL NOT
or MAY be included.
Clear guidance on
what sections a
particular type of
document MAY,
SHOULD or
SHALL contain
Indicates the type of
section template that
SHALL, SHOULD or MAY be
applied
Example template
Object Identifier (OID) in
a conforming document
instance.
Constraint statements shown are illustrative only
2013-May-28
PITO & GPi
35
Specification Overview
Developer Friendly
tabular view
Consistent Formats for all
templates
Hot linked, formal
constraint statements
Hot linked, formal
vocabulary bindings
Constraint statements shown are illustrative only
2013-May-28
PITO & GPi
36
Specification Overview
• Linked vocabulary
• Consolidated,
developer-friendly
view showing key
info (e.g. OIDS)
• Guides can include
all, none or a sample
set of values based
on a simple field in
the tool
Sample
2013-May-28
PITO & GPi
37