PCC TF-1/PHLAB/XDSLAB Harmonization
NOTE: As of August 2008, this work has been harmonized with XD-Lab v2.1 volume 3 'Content'. Please see this profile for the official documentation.
Back to: PCC_TF-1/PHLAB
Intro
The use of content modules in XDS-Lab helps lab remain consistent with what other domains have accomplished as well as insures that the lab domain provides guidance to the other domains as they incorporate relevant laboratory data into their own content profiles.
Benefits:
- Consistency with work done in other domains (example annotation comment)
- Provide guidance to other domains incorporating laboratory data (example PCC)
- Provide context to section of CDA (example intended recipient)
Laboratory Report Summary Integration Profile
This Content Integration Profile describes a clinical laboratory report as an electronic document to be published towards a document sharing resource such as an Electronic Health Record (EHR) or in Personal Health Record (PHR) shared by a community of care providers, using one of the document sharing profiles defined in ITI-TF.
Such an electronic document contains the set of releasable results produced by a clinical laboratory in fulfillment of one or more test Orders for a patient. The report is shared in a human-readable format. In addition, this electronic laboratory report SHALL contain test results in a machine-readable format, to facilitate the integration of these observations in the database of a consumersystem.
The scope covers all laboratory specialties except anatomic pathology. The human rendering of the laboratory report defined in this Integration Profile is compatible with laboratory regulations in numerous countries, including CLIA in the USA, GBEA in France.
The laboratory report described in this profile, with its set of test results in a machine-readable format, may also be used to share historical results with appropriate content anonymization and patient identification pseudonimization to create shared distributed repositories of laboratory information (Section 9, LTF vol 1).
The motivation for integrating this profile with the public health use case as follows:
- Show that the same standards that support the current IHE profiles for clinical care interoperability can be leveraged by public health.
- Encourage the public health community to come forward to IHE with use cases to further enhance data sharing.
Leveraging the CDA R2 standard and XDS-LAB make the resultant document consumable by public health and incorporable in an effected patient’s medical record thereby completing a communication loop between individual and public care.
Dependencies
Add the following row(s) to the list of dependencies
| Integration Profile | Dependency | Dependency Type | Purpose |
|---|---|---|---|
| XDS-Lab | CDA R2 | XDS-Lab is a conformant CDA R2 document | XDS-Lab constrains CDA R2 for the purposes of communicating any Laboratory Report |
Actors/Transaction
There are two actors in the XDS-Lab profile, the Content Creator and the Content Consumer. Content is created by a Content Creator and is to be consumed by a Content Consumer. The sharing or transmission of content from one actor to the other is addressed by the appropriate use of IHE profiles described below, and is out of scope of this profile. A Document Source or a Portable Media Creator may embody the Content Creator Actor. A Document Consumer, a Document Recipient or a Portable Media Importer may embody the Content Consumer Actor. The sharing or transmission of content or updates from one actor to the other is addressed by the use of appropriate IHE profiles described in the section on Content Bindings with XDS, XDM and XDR.
Options
| Actor | Option |
|---|---|
| Content Consumer | View Option (1) |
| Document Import Option (1) | |
| Section Import Option (1) | |
| Discrete Data Import Option (1) |
Content Consumer Options
View Option
This option defines the processing requirements placed on Content Consumers for providing access, rendering and management of the medical document. See the View Option in PCC TF-2 for more details on this option.
A Content Creator Actor should provide access to a style sheet that ensures consistent rendering of the medical document content as was displayed by the Content Consumer Actor.
The Content Consumer Actor shall be able to present a view of the document using this style sheet if present.
Document Import Option
This option defines the processing requirements placed on Content Consumers for providing access, and importing the entire medical document and managing it as part of the patient record. See the Document Import Option in PCC TF-2 for more details on this option.
Section Import Option
This option defines the processing requirements placed on Content Consumers for providing access to, and importing the selected section of the medical document and managing them as part of the patient record. See the Section Import Option in PCC TF-2 for more details on this option.
Discrete Data Import Option
This option defines the processing requirements placed on Content Consumers for providing access, and importing discrete data from selected sections of the medical document and managing them as part of the patient record. See the Discrete Data Import Option in PCC TF-2 for more details on this option.
Coded Terminologies
This profile supports the capability to record entries beyond the IHE required coding associated with structured data. Actors from this profile may choose to utilize coded data, but interoperability at this level requires an agreement between the communicating parties that is beyond the scope of this Profile.
To facilitate this level of interoperability, the applications that implement actors within this profile shall provide a link to their HL7 conformance profile within their IHE Integration statement. The conformance profile describes the structure of the information which they are capable of creating or consuming. The conformance profile shall state which templates are supported by the application implementing the profile Actors, and which vocabularies and/or data types are used within those templates. It should also indicate the optional components of the entry that are supported.
An Example HL7 Conformance Profile is available to show how to construct such a statement. See the HL7 Refinement Constraint and Localization for more details on HL7 conformance profiles.
Content Bindings with XDS, XDM and XDR
Cross Enterprise Document Sharing, Media Interchange and Reliable Messaging
Actors from the ITI XDS, XDM and XDR profiles embody the Content Creator and Content Consumer sharing function of this profile. A Content Creator or Content Consumer may be grouped with appropriate actors from the XDS, XDM or XDR profiles to exchange the content described therein. The metadata sent in the document sharing or interchange messages has specific relationships or dependencies (which we call bindings) to the content of the clinical document described in the content profile.
The Patient Care Coordination Technical Framework defines the bindings to use when grouping the Content Creator of this Profile with actors from the IHE ITI XDS, XDM or XDR Integration Profiles.
| Content | Binding | Actor | Optionality |
| Laboratory Report Summary | Medical Document Binding to XD* | Content Creator | R |
| Content Consumer | R |
XDS Metadata Binding
NOTE: These bindings are subject to the following CPs on CDA Metadata (see here) and (see here)
XDS-Lab is a CDA R2 document and thus conforms to the XDS Metadata requirements in the PCC-TF, volume 2, Section 5 unless otherwise specified below.
XDSDocumentEntry
XDS-Lab leverages the XDS DocumentEntry Metadata requirements in the PCC-TF, volume 2, Section 5.1.1.1.1 and in PCC_TF-2/Bindings unless otherwise specified below
XDSDocumentEntry.eventCodeList
XDS-Lab documents further constrain the the XDSDocumentEntry.eventCodeList to the following.
| Attribute | Optional? | Source Type | Source/ Value |
|---|---|---|---|
| eventCodeList | R2 | SAT | ClinicalDocument / component / structuredBody / component / section / entry / act / entryRelationship / organizer (templateId="1.3.6.1.4.1.19376.1.3.1.1")/ component / observation(templateId="1.3.6.1.4.1.19376.1.3.1.1.1")/value
AND ClinicalDocument / component / structuredBody / component / section / entry / act / subject / code If the document has Reportable Condition, then this code shall be among those listed in the eventCodeList. Additionally, if the document contains information about a Non-Human Subject, then the code that indicates what this subject is shall be among those listed in the eventCodeList. Thus, this attribute has been enhanced from the XDS profile from O to R2. |
XDSDocumentEntry.formatCode
The XDSDocumentEntry.formatCode shall be urn:ihe:lab:xd-lab:2008
XDSDocumentEntry.parentDocumentRelationship
XD-Lab only permits the replace relationship between instances of XD-Lab documents. Thus, XDSDocumentEntry.parentDocumentRelationship is constrained to only the "RPLC" value.
XDSSubmissionSet
No additional constraints. For more information, see PCC-TF-2 Section 5.1.1.1.2 or PCC_TF-2/Bindings.
XDSFolder
No additional requirements. For more information, see PCC-TF-2 Section 5.1.1.1.3 or PCC_TF-2/Bindings.
XDS-Lab Document Content Module
Use Case 1: Hospital physician feeding the patient record of an affinity domain
During his stay in a hospital, patient John Smith has had several clinical laboratory orders. At discharge time, a hospital physician selects the most significant reports produced by various facilities, including lab reports, and issues these reports individually to a health information exchange (e.g. XDS Affinity Domain) shared by a number of healthcare enterprises and primary care providers. Thus later on, during a new episode of care, the care provider of John Smith (e.g. his family doctor) will be able to access the previous lab reports of the patient through a healthinformation exchange (e.g. XDS Affinity Domain).
In this example, the electronic laboratory report is produced by the system that played the role of Order Result Tracker, and sent to the external health information exchange upon request from the medical staff preparing the discharge summary (Section 9, LTF vol 1).
Use Case 2: Private laboratory feeds the patient record of an affinity domain
Patient Jane Smith with a suspected urinary infection has been sent by her family doctor to any private laboratory downtown, with an order for a CBC and a urine microscopy and culture. Jane Smith enters into the nearest laboratory with a urine specimen, sees a phlebotomist who collects a venous blood specimen from her, and then leaves the laboratory. In this laboratory all the work on the request (hematology and microbiology) is reported together. Two days later the clinical laboratory addresses its paper report to Jane’s family doctor (outside of this use case) and in the same time sends this report in an electronic format to the national EHR to feed the record of Jane Smith (Section 9, LTF vol 1).
Patient Jane Smith, with a suspected urinary infection is seen by her family doctor who collects a urine sample and sends it to a reference laboratory with an order for a urine microscopy and culture. The laboratory returns the tests results (outside of this use case) to the family doctor who reviews the results, and notifies Jane Smith of her treatment. The doctor, as requested by Jane Smith, shares this laboratory report in Jane’s personal health record in an electronic format (Section 9, LTF vol 1).
Use Case 4: Case Report for a Public Health Reportable Condition with Laboratory Component
A Public Health Laboratory Report content document is a type of laboratory report, and incorporates the constraints defined for laboratory reports found in the XDS-Lab specification. By leveraging the CDA R2 standard and XDS-LAB, a XDS-Lab document for public health is consumable by public health and incorporable in an effected patient’s medical record thereby completing a communication loop between individual and public care.
Reality Today:
John Doe, MD sees a patient and suspects that this patient has an enteric pathogen. The patient follows through on the doctor’s orders and submits a stool specimen to the clinic's laboratory. Upon completion of laboratory analysis, the laboratory confirms the presence of Salmonella and performs susceptibility testing. When a microbiologist has time in the week, they gather all the reportable results and complete the forms for submission to the public health agency. Additionally, the clinical laboratory needs to submit the Salmonella specimen to the public health laboratory for serotyping and outbreak surveillance. This specimen is mailed along with a hand written requisition to the public health laboratory for epidemiological serotyping.
The public health laboratory enters the partial information written on the requisition and identifies the Salmonella serotype. A nightly batch process reports the serotype to the submitting clinician. A monthly batch process generates a file for the Disease Control agency. Nearby surveillance regions have small clusters of cases with this same Salmonella serotype but without knowledge of the other cases, no outbreak investigation is initiated.
The Disease Control agency detects this anomaly as monthly reports are received when observed across surveillance regions and an outbreak protocol is started to investigate the potential outbreak. The Disease Control agency requests PFGE (pulse field gel electrophoresis) on the known samples and the outbreak is finally confirmed two months later. Calls, faxes, and emails are used to transmit information to relevant regional and local programs as well as the submitters of outbreak samples. Significant efforts on identification, investigation, and resolution focus on getting the desired data to the necessary participants. The outbreak is investigated and linked to a restaurant supplier in a popular but off-season resort area.
After this profile is adopted:
Preconditions: The clinical laboratory creates a laboratory report identifying the organism as a Salmonella isolate and that further serotyping will be done at the Public Health Lab. The laboratory report is sent to the clinician, stored within the patient’s electronic medical record, and registered in a clinical interoperability registry. The isolate is mailed to the public health lab.
Events: Upon arrival, the public health laboratory receiving department queries the clinical interoperability registry with the submitter’s patient ID and views the initial laboratory report. The public health laboratory information system pulls forward the patient’s demographic and specimen data from the initial laboratory report. The public health laboratory creates a new laboratory report identifying the Salmonella serotype. This report is sent to the clinician, stored within the patient’s electronic medical record, registered in the clinical interoperability registry, registered in the regional public health interoperability registry, and registered in the national public health interoperability registry.
The Disease Control agency monitors the national public health registry for new cases of Salmonella. An anomaly is immediately detected in the number of new cases for this particular Salmonella serotype when observed across regional surveillance boundaries and an outbreak protocol is started immediately to investigate the potential cross-border outbreak. The Disease Control agency requests PFGE (pulse field gel electrophoresis) on the current samples and alerts all public health laboratories to perform PFGE on new samples of this serotype. The outbreak is confirmed quickly and new cases are identified and tracked seamlessly.
Post conditions: Local, regional, and national epidemiologists and case workers have access to all laboratory reports within their respective interoperability registries and may potentially gain further access to the clinical interoperability registry for additional information, such as the ordering provider and care location, for initiating further investigation.
Key improvements include:
- avoid handwritten forms and data re-entry
- ease transition of data to and from clinical care and public health agencies
- ease transition of data from one public health agency to another
- monitor registries for anomalies in a real-time basis
- response protocols focus on response, not the access to data
Links with Laboratory Workflow messaging
In all use cases above, the laboratory report document is built and published towards a document sharing resource, generally after the Order or Order Group is fulfilled. It is usually a final report. Yet in some cases a preliminary report can also be shared. In all cases the laboratory report document will not be carried by the laboratory results messages of the Laboratory Scheduled WorkFlow.
In all use cases above, the laboratory report is built with a set of releasable results. The report may be preliminary or final. Further updates of this report must be supported (e.g. replace, deprecate).
In use case 2 the report is produced by the LIS that played the role of Order Filler during the laboratory scheduled workflow. The Content Creator Actor is coupled with the Order Filler Actor. In use case 1 the report is produced by the application that played the role of Order Result Tracker during the laboratory scheduled workflow. The Content Creator Actor is coupled with the Order Result Tracker Actor (Section 9.4, LTF vol 1).
Grouping with Other Actors
Cross Enterprise Document Sharing, Media Interchange and Reliable Messaging
The Content Creator and Content Consumer Actors shall be grouped with appropriate actors from the XDS, XDM or XDR integration profiles to support sharing of PHLab documents.
Document Digital Signature (DSG)
Content Creator actors should digitally sign all documents using the Digital Signature (DSG) Content Profile.
Content Consumer actors should verify the Digital Signature of the submission set before use of the information it contains.
CDA Document Content Modules
- XDS Laboratory Report Clinical Document Specification (1.3.6.1.4.1.19376.1.3.3)
CDA Header Content Modules
- Human Patient - DEPRECATED (1.3.6.1.4.1.19376.1.3.3.1.1)
- Non-Human Subject (1.3.6.1.4.1.19376.1.3.3.1.2)
- Human Patient with Non-Human Subject (1.3.6.1.4.1.19376.1.3.3.1.3)
- Intended Recipient (1.3.6.1.4.1.19376.1.3.3.1.4)
- Laboratory Result Verifier(1.3.6.1.4.1.19376.1.3.3.1.5)
- Referral Ordering Physician (1.3.6.1.4.1.19376.1.3.3.1.6)
- Laboratory Performer(1.3.6.1.4.1.19376.1.3.3.1.7)
CDA Section Content Modules
- Laboratory Specialty Section (1.3.6.1.4.1.19376.1.3.3.2.1)
- Laboratory Report Item Section (1.3.6.1.4.1.19376.1.3.3.2.2)
CDA and HL7 Version 3 Entry Content Modules
- Modules unique to the document body
- Laboratory Report Data Processing Entry (1.3.6.1.4.1.19376.1.3.1)
- Notification Organizer (1.3.6.1.4.1.19376.1.3.1.1)
- Notifiable Condition (1.3.6.1.4.1.19376.1.3.1.1.1)
- Case Identification (1.3.6.1.4.1.19376.1.3.1.1.2)
- Outbreak Identification (1.3.6.1.4.1.19376.1.3.1.1.3)
- Specimen Collection (1.3.6.1.4.1.19376.1.3.1.2)
- Specimen Received (1.3.6.1.4.1.19376.1.3.1.3)
- Specimen Site (1.3.6.1.4.1.19376.1.3.1.8)
- Laboratory Battery Organizer (1.3.6.1.4.1.19376.1.3.1.4)
- Laboratory Isolate Organizer (1.3.6.1.4.1.19376.1.3.1.5)
- Laboratory Observation (1.3.6.1.4.1.19376.1.3.1.6)
- Annotation Comment (PCC) (1.3.6.1.4.1.19376.1.5.3.1.4.2)
- Modules with counterparts in the cda header
- Non-Human Subject (1.3.6.1.4.1.19376.1.3.3.1.2.1)
- Human Patient with Non-Human Subject (1.3.6.1.4.1.19376.1.3.3.1.3.1)
- Laboratory Result Verifier (1.3.6.1.4.1.19376.1.3.3.1.5)
- Laboratory Performer(1.3.6.1.4.1.19376.1.3.3.1.7)
Proposed Modules
- Specimen Storage (1.3.6.1.4.1.19376.1.3.1.9)
OPEN ISSUES
- Metadata CP to PCC TF-PCC-CP-0030, and TF-PCC-CP-0032
- alignment with CCD? CRS?
- missing codes (LOINC) - specimen collection, specimen received
- additional cp's (issues) to base XDS-Lab/PCC text (ex. SNOMED doc code, Laboratory Observation requirements, etc.)
- end result documentation - in PCC, in XDS-Lab? movement towards a domain independent CDA R2-based content framework?