Table of Contents minLevel 2
| minLevel | 2 |
|---|
Overview of OpenCDS Components
Last updated April 21, 2011 by Ken Kawamoto
Last updated November 21, 2011 by David Shields
Last updated June 25, 2014 by David Shields
Document purpose:
- To provide an overview of the current components of OpenCDS
General notes:
- For a big-picture overview of the OpenCDS approach, please see OpenCDS Home, and in particular the sub-sections on Architecture, Key Components, and References.
- For instructions on how to download and install these resources, please see other relevant documentation in the Documents section.
- OpenCDS version 1.2.x is intended to support production deployment. Certain capabilities needed for production deployment (e.g., hot-updating of knowledge bases) will be implemented in this release.
Document sections:
- Overview of virtual medical record (vMR) model
- Overview of Java code base
- Overview of use of Apelon DTS terminology service
- Overview of Drools Guvnor knowledge authoring environment
Overview of vMR model
- The current OpenCDS vMR version 1.0 Domain Analysis Model (DAM) and logical data model are available at
- http://develop.opencds.org/OpenCDSProjectDocs/latest/HL7vMR_vMR_Domain_Analysis_Model_2011_Sept_Ballot.pdf
- http://develop.opencds.org/OpenCDSProjectDocs/latest/vMR_DAM_R2.zip (this is vMR 1.0 with minor corrections, not the HL7 balloted vMR 2.0)
- http://develop.opencds.org/OpenCDSProjectDocs/latest/vMR_DAM_R2.EAP (this is vMR 1.0 with minor corrections, not the HL7 balloted vMR 2.0)
- Its primary content is vMR_DAM.eap, which is an Enterprise Architect UML model for the HL7-balloted vMR.
- The version 1.0 vMR is based on the HL7 CCD and the HL7 clinical statement pattern.
- The vMR logical data model is expressed within OpenCDS by both
- an external schema which is designed to be populated from either structured data (such as CCD) or relational data (such as from an enterprise data warehouse), and
- an internal java beans structure which is optimized for use within Drools fact lists.
Overview of Java code base
- This is a guided walk-through of the OpenCDS Java code base
- The current OpenCDS Java code base is available in the opencds-parent package in bitbucket.
- Overall approach
- We are using Maven for the build process, Eclipse for the development environment, and bitbucket for the source repository
- We view the version 1.0 release (as of January, 2012) as the initial production-capable version of OpenCDS. There have been a half-dozen releases since then, and we are currently at 1.2.0
- The various sub-projects are all contained within the overall opencds-parent project. This allows all sub-projects to be built together using the “Maven clean” and “Maven install” commands on the opencds-parent project.
- The following sections give a walk-through of the sub-projects of opencds-parent.
- dss-java-stub
- Java implementation of normative OMG Decision Support Service (DSS) specification, for SOAP Web services.
- Stub code, auto-generated using Apache CXF.
- opencds-common
- Contains common components used throughout OpenCDS. These include general utilities, core structural elements (e.g., for CS and CD data types), and classes for assisting with the manipulation of XML.
- The AbsoluteTimeDifference class is particularly useful for conducting time-based inferencing in an intuitive manner.
- opencds-config This sub-project handles the configuration properties files
- opencds-config-api
- opencds-config-schema
- opencds-decision-support-service
- This sub-project instantiates a standards-compliant DSS as a .war file that can be deployed in Tomcat or other application server using the OpenCDS vMR and knowledge resources. By default, knowledge resources are created using Drools Guvnor, but the code is designed to allow the use of other inference engines, and other Drools technologies than Guvnor to create the knowledge resources.
- Currently, only the Evaluation interface is fully implemented. The Query and Metadata Management interfaces will be implemented as the need for them grows.
- The main class handling the service is DroolsAdapater. It takes in an evaluation request, converts the external vMR into the internal vMR, and executes one knowledge base (rule) at a time. Each knowledge base (rule) corresponds to a “package” in Drools Guvnor. The results are then sent back to the end user.
- The first time a knowledge base is called, there is a few second delay as the knowledge base is loaded. Subsequent calls are very fast due to the knowledge base already having been loaded into memory.
- Currently, knowledge bases are created in Drools Guvnor and then saved into opencds-drools-service as a .drl or .pkg resource file. In the future, we intend to convert this to a database-driven approach to allow for hot-updating of knowledge bases.
- opencds-dss-components
- opencds-dss-drools-55-adapter - the default evaluation engine adapter furnished by OpenCDS to interface with Drools v5.5
- opencds-dss-evaluation - implementation of DSS operation with methods to determine what evaluation engine adapter is required for a given rule (e.g., opencds-dss-drools-55-adapter), and to instantiate and pass data and control to it
- opencds-dss-metadata-discovery - standard DSS operation method stub, not yet implemented
- opencds-dss-query - standard DSS operation method stub, not yet implemented
- opencds-dss-sample-java-engine - sample stub code for writing a simple inference engine in Java, not fully implemented.
- opencds-guvnor-support
- This sub-project is provided for the development of functions to be used in Guvnor
- opencds-knowledge-repository is intended to be expanded to an alternate optional repository using a database
- opencds-knowledge-repository-file-based
- This module contains a repository for KnowledgeModules (aka “Rules”), OpenCDSConcept terminology mappings, and other associated information that is needed by OpenCDS at run-time.
- It contains methods to store and retrieve updateable information in file-based structures.
- opencds-knowledge-repository-file-based
- opencds-mgmt-interface - This sub-project provides interfaces for management of the OpenCDS run-time.
- docs
- opencds-mgmt-restlet
- opencds-mgmt-support
- opencds-terminology-support
- opencds-terminology-serivce is an abstract class that other OpenCDS sub-projects can interact with in order to obtain terminology inferencing capabilities through a common interface.
- opencds-simple-terminology-service
- This sub-project is a concrete implementation of the abstract opencds-terminology-service. It provides an implementation based on XML resource files, e.g., that specify mappings between codes from standard terminologies and OpenCDS concepts.
- The ApelonResourceCreator class in this sub-project enables users of compatible Apelon DTSs to create the XML resource files required by the service via relevant entries in the DTS.
- We intend to convert to a database-driven approach to managing the terminology content currently contained in the XML resource files.
- opencds-apelon
- Contains an ApelonDtsUtility that provides convenience methods for interacting with the open-source Apelon DTS terminology server.
- Note that Apelon is NOT required for using OpenCDS. The architecture allows for the use of any number of terminology servers.
- opencds-vmr-v1_0 (grouper containing following 3 modules)
- opencds-vmr-v1_0-schema
- This sub-project contains the XML schema for the vMR, as well as the Java classes auto-generated from the schema via JAXB. This vMR is referred to as the external vMR.
- Opencds-vmr-v1_0-mappers
- This module contains classes to map input data from external schema format to internal java beans format, and to map output data from the internal format back into the external XML structure.
- opencds-vmr-v1_0-internal
- This sub-project contains the vMR that is used internally for knowledge authoring using the Drools Guvnor platform. It is conceptually equivalent to the external vMR model.
- Introduced in the internal vMR is the notion of an OpenCdsConcept. This approach is critical to the functioning of OpenCDS. Essentially, it associates a code system and code (e.g., CD data type) to 0…* OpenCDS “concepts” as well as the method used to determine that the code system and code implies that concept.
- Examples:
- ICD9CM 250.00 → OpenCDS concept of diabetes mellitus
- NDC XYZ → OpenCDS concepts of lisinopril and ACE inhibitor - The use of OpenCdsConcepts enables a clear separation of concerns between terminology mapping and logic authoring. Within Guvnor, knowledge engineers only need to worry about OpenCdsConcepts, which populate drop-down lists to facilitate knowledge authoring.
- The ability to specify concept determination methods is critical. In most cases for clinical inferencing, concept mappings can be specified as using the “best available concept determination method,” which allows these mappings to be updated independently of the knowledge resources. However, especially for quality measures that require specific, versioned mapping approaches, it allows, e.g., a concept mapping to be specified as having been determined via “HEDIS 2009”, “HEDIS 2010”, “NQF”, etc.
- An open, important issue is whether a single OpenCDS terminology resource could be used across OpenCDS deployments. This would maximize knowledge re-use.
- Examples:
- This sub-project also includes several utilities, including an EnumerationUtility for loading enumerations into Guvnor, a MappingUtility to assist with conversions between the internal and external vMRs, and a LogicHelperUtility to assist with logical inferencing in Guvnor.
- opencds-vmr-v1_0-schema
Overview of Apelon DTS terminology service
- The current OpenCDS implementation leverages, but does not require, the open-source Apelon DTS. Apelon is an OpenCDS collaborator and has made available a download of its terminology content for use in OpenCDS development. The DTS terminology editor is free and open-source.
- The approach to using Apelon will likely undergo significant updates in the next several months, as key project members will be transitioning to the University of Utah, where there is significant existing expertise and resources related to Apelon that we intend to leverage.
- We will be investigating the use of other terminology management tooling as well.
- Because installation of an Apelon instance requires non-trivial effort, as noted above, the simplest approach at this point is to edit the XML resource files in opencds-simple-terminology-service to effect terminology changes within OpenCDS.
- We need to explore how best to share terminology resources, and the definition of common concepts, across OpenCDS implementations.
- Essentially, Apelon is used to do the following at present:
- Maintain an OpenCDS terminology that specifies OpenCDS concepts used.
- Define mappings of OpenCDS concepts to terms from standard terminologies, using subsets (e.g., CPT codes for Pap test, as defined by NQF for Meaningful Use quality measures).
- Maintain an OpenCDS terminology that specifies OpenCDS concepts used.
Overview of Drools Guvnor knowledge authoring platform
- Drools Guvnor is the Web-based knowledge authoring platform for the open-source JBoss Drools business rules engine. It is still maturing, and does have limitations and bugs. However, it is under very active development and is getting better rapidly.
- We intend for OpenCDS to eventually support multiple knowledge authoring platforms, including XML/XSD-based knowledge authoring and knowledge authoring based on the Eclipse Drools knowledge editing platform. However, based on our analysis, we have concluded that Drools Guvnor is a highly promising platform to serve as our initial foundation for OpenCDS knowledge authoring. In particular, its ability to provide an intuitive user interface (when properly configured) and its ability to be deployed through a Web browser are highly appealing.
- The current OpenCDS implementation uses the latest public release version of Guvnor (version 5.1.1). We plan to migrate to newer versions when they become available. In particular, the latest developer versions have significantly enhanced capabilities with regard to table-driven knowledge editing and the use of flow diagrams to specify logic. We intend to investigate and incorporate these approaches as we move forward.
- In developing the OpenCDS Guvnor platform, our objective was as follows:
- Make it as easy as possible for a knowledge engineer to implement rules
- Make it as intuitive as possible for clinicians with minimal training to be able to review the implemented rules (and NOT a separate documentation of the rules) to verify the content and to recommend edits as necessary. The lack of support for this feature can make knowledge maintenance very difficult, as the specifications approved by clinicians can easily diverge from what is actually implemented and in production. We believe the current approach meets these two objectives well.
- Drools Guvnor currently has relatively weak metadata support. We will need to either have Guvnor extended to support better metadata management, or create a separate, linked resource for more proper metadata management.
- After much deliberation, we have settled on the following grouping/organization of knowledge resources at this point:
- Global area → place re-usable, common content
- To facilitate conceptual simplicity, we have mapped a single DSS knowledge module to a single Guvnor package. Each Guvnor package may contain multiple individual Drools rules.
- There are several components within a given Guvnor package:
- Model → the data model used (jar for internal vMR). Note that the drools-guvnor webapp contains libraries for other OpenCDS jars required by the rules.
- Enumerations → primarily populated from Apelon. Also, manually specified enumerations for the equivalent of local variables used within a package (see below for example).
- Domain Specific Language (DSL) configurations → this is at the heart of the OpenCDS knowledge authoring platform. It provides specifications of how human-readable text is translated into underlying Drools logic.
- Business rule assets → the actual rules.
- Functions -> provide support for more complex calculations when needed
- Test scenarios → various test cases to test boundary conditions, etc.
- We have include two sample knowledge bases/packages: one for the NQF Meaningful Use quality measure for breast cancer screening (NQF 0031), and one for the NQF Meaningful Use quality measure for Pap testing (NQF 0032). Provided below is a brief guided tour through the 4 rules that comprise the Guvnor package for the NQF quality measure for breast cancer screening:
Rule “Pre_RequireConceptDeterminationMethod_NQF”
- This rule has a salience of 100, which means that it will be run before other rules. The use of the “Pre_” prefix on the rule name is a convention to indicate it is a pre-processing rule.
- This rule states that if an OpenCDS concept within the vMR was not determined according to the NQF methodology, than that concept should be removed. This rule essentially ensures that only terminology bindings that have been made in the manner specified by the latest available NQF approach will be accepted.
- Note that currently, the concept determination method of NQF does not have a version associated with it (e.g., NQF_v2011). This is because NQF is apparently working on a terminology versioning approach but has not implemented it yet, at least in their published artifacts. Having versions for terminology mapping is important for quality measurement, where the use of a specific mapping approach is required for reporting purposes.
Rule “DenomCriteriaMet”
- This rule determines whether a patient meets denominator criteria (i.e., is eligible for breast cancer screening)
- Note that the text is quite human readable – this is through the use of DSL patterns.
- Concepts are accessed via drop-down lists specific to the type of concept involved (e.g., problem vs. encounter type). These are populated based on entries in the terminology resource.
- Note how similar this specification looks (and potentially looks simpler) than the human-readable NQF 0031 specification provided by NQF via this link, and copied below:
- In the rule above, note that when the denominator criteria are met, the rule asserts that “NQF 0031 denominator criteria met”. This Assertion represents an internal variable, whose enumerated values are defined in a package-specific manner in the Enumerations section of the package:
- The above approach allows for an easy way to handle intermediate variables and conclusions. Also, a NamedObject can be used to define more complex internal variables that need to be associated with specific facts in the current model.
- Note that this assertion could have been represented using a semantically self-identifying object (e.g., an Observation with a code indicating it is an assertion regarding the NQF 0031 quality measure and a value of true). We are still trying to identify when it is best to use one approach over the other. This will be an active area of learning.
- Also, note the following when viewing the actual DRL syntax that this rule gets translated into (visible through the “View Source” option for the rule; example below shown for the statement that the patient has had an outpatient encounter in the past 2 years):
- There is a lot of complex handling occurring in the back-end. The use of DSLs allows for intuitive and consistent specification of such complex logic.
- There is a comment at the end that notes the DSL used and the parameters chosen (e.g., the concept of interest and the timeframe of interest). Our intention is to use these comments to identify data requirements for each DSS knowledge module/Guvnor package, which can then be automatically compiled into data requirements that are communicated to end-users via the DSS Query interface.
Rule “NumCriteriaMet”
- This rule is similar to the denominator rule; it specifies that numerator criteria have been met if the patient has had a breast cancer screening in the past 2 years.
- As a miscellaneous note, the “Initialize” statement is required due to limitations with how global variables are handled within the Guvnor test environment. Once the issue is resolved, we will be able to remove the initialization statement.
Rule “Post_CreateOutput”
(rule separated into 2 pieces due to length – a current limitation of Guvnor is that line breaks cannot be inserted into DSL templates)
- This rule uses a DSL pattern to create a quality measure output based on assertions made, for the NQF quality measure specified (the OID of the NQF 0031 measure, as specified by NQF)
- This rule runs after the other rules, and it populates the KMEvaluationResult that is returned to the DSS client. For example, the following is the output returned to a DSS client following the evaluation of a patient who meets both denominator and numerator criteria:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<ns2:evaluateAtSpecifiedTimeResponse xmlns:ns2="http://www.omg.org/spec/CDSS/201105/dss">
<evaluationResponse>
<finalKMEvaluationResponse>
<kmId scopingEntityId="org.opencds" businessId="NQF_0031_v1" version="1.0.0"/>
<kmEvaluationResultData>
<evaluationResultId itemId="PrimaryEvaluationResult"/>
<data>
<informationModelSSId scopingEntityId="org.opencds.vmr" businessId="KMEvaluationResult" version="1.0.0"/>
<base64EncodedPayload>[base64 payload; see below for contents]</base64EncodedPayload>
</data>
</kmEvaluationResultData>
</finalKMEvaluationResponse>
</evaluationResponse>
</ns2:evaluateAtSpecifiedTimeResponse>
</soap:Body>
</soap:Envelope>
|
- A sample of the contents of [base64 payload] above, converted via http://ostermiller.org/calc/encode.html, is provided on the following pages (with relevant emphases).
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8"?>
<in:cdsInput xmlns:in="org.opencds.vmr.v1_0.schema.cdsinput"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dt="org.opencds.vmr.v1_0.schema.datatypes"
xsi:schemaLocation="org.opencds.vmr.v1_0.schema.cdsinput ..\schema\cdsInput.xsd">
<templateId root="2.16.840.1.113883.3.795.11.1.1" />
<!--<cdsResource/> -->
<!--cdsContext is optional -->
<cdsContext>
<!--<cdsSystemUserType code="" codeSystem="" displayName=""/> -->
<cdsSystemUserPreferredLanguage code="en"
codeSystem="1.2.3" displayName="English" />
<!--<cdsInformationRecipientType code="" codeSystem="" displayName=""/> -->
<!--<cdsInformationRecipientPreferredLanguage code="" codeSystem="" displayName=""/> -->
<!--<cdsSystemUserTaskContext code="" codeSystem="" displayName=""/> -->
</cdsContext>
<vmrInput>
<templateId root="2.16.840.1.113883.3.795.11.1.1" />
<patient>
<id root="2.16.840.1.113883.19.5" extension="996-756-495" />
<!--alternate form of id: <id root="aGUID"/> -->
<demographics>
<birthTime value="19830630" />
<gender codeSystem="1.2.3" code="F" />
</demographics>
<clinicalStatements>
<!-- allergies -->
<adverseEvents>
<adverseEvent>
<id root="2.16.840.1.113883.3.795.10.1" extension="7478551" />
<!-- Allergic reaction to substance (disorder) -->
<adverseEventCode code="2.16.840.1.113883.6.96"
codeSystem="418634005" />
<!-- Eggs (edible) (substance) -->
<adverseEventAgent code="2.16.840.1.113883.6.96"
codeSystem="256442007" />
<documentationTime low="200003231430" high="200003231430" />
<adverseEventStatus code="2.16.840.1.113883.6.96"
codeSystem="55561003" />
</adverseEvent>
</adverseEvents>
<!--lab results, using optional nested structure for panel -->
<observationResults>
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.32" /> <!-- Result organizer template -->
<id root="107c2dc0-67a5-11db-bd13-0800200c9a66" />
<observationFocus code="43789009" codeSystem="2.16.840.1.113883.6.96"
displayName="CBC WO DIFFERENTIAL" />
<observationEventTime low="20110803" high="20110803" />
<observationValue />
<relatedClinicalStatement>
<targetRelationshipToSource
codeSystem="2.16.840.1.113883.5.1002" code="COMP" />
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.31" /> <!-- Result observation template -->
<id root="33d27880-eb74-11e0-9572-0800200c9a66" />
<observationFocus code="30313-1" codeSystem="2.16.840.1.113883.6.1"
displayName="HGB" />
<observationEventTime low="20110803" high="20110803" />
<observationValue>
<physicalQuantity value="13.2" unit="g/dl" />
</observationValue>
<interpretation code="N" codeSystem="2.16.840.1.113883.5.83" />
</observationResult>
</relatedClinicalStatement>
<relatedClinicalStatement>
<targetRelationshipToSource
codeSystem="2.16.840.1.113883.5.1002" code="COMP" />
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.31" /> <!-- Result observation template -->
<id root="33d27881-eb74-11e0-9572-0800200c9a66" />
<observationFocus code="33765-9" codeSystem="2.16.840.1.113883.6.1"
displayName="WBC" />
<observationEventTime low="20110803" high="20110803" />
<observationValue>
<physicalQuantity value="6.7" unit="10+3/ul" />
</observationValue>
<interpretation code="N" codeSystem="2.16.840.1.113883.5.83" />
</observationResult>
</relatedClinicalStatement>
<relatedClinicalStatement>
<targetRelationshipToSource
codeSystem="2.16.840.1.113883.5.1002" code="COMP" />
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.31" /> <!-- Result observation template -->
<id root="33d27882-eb74-11e0-9572-0800200c9a66" />
<observationFocus code="26515-7" codeSystem="2.16.840.1.113883.6.1"
displayName="PLT" />
<observationEventTime low="20110803" high="20110803" />
<observationValue>
<physicalQuantity value="123" unit="10+3/ul" />
</observationValue>
<interpretation code="L" codeSystem="2.16.840.1.113883.5.83" />
<relatedEntityInRole>
<targetRole codeSystem="HL7-OID" code="appropriateCode"
displayName="Lab Technician" />
<person>
<id root="71ea2b7d-e6dd-4d72-a8e2-ff69862db52d" />
<name use="C">
<part type="GIV" value="Jane" />
<part type="FAM" value="Doe" />
</name>
<telecom value="tel:801-123-4567" use="WP" />
<telecom value="mailto:jane@lab.com" use="WP" />
</person>
</relatedEntityInRole>
</observationResult>
</relatedClinicalStatement>
</observationResult>
<!--a different set of lab results, using alternate listed structure
in lieu of nested structure above -->
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.32" /> <!-- Result organizer template -->
<id root="33d27883-eb74-11e0-9572-0800200c9a66" />
<observationFocus code="20109005" codeSystem="2.16.840.1.113883.6.96"
displayName="LYTES" />
<observationEventTime low="20110803" high="20110803" />
<observationValue />
</observationResult>
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.31" /> <!-- Result observation template -->
<id root="e814debb-8a47-451b-8f01-f4b7f2beeba1" />
<observationFocus code="2951-2" codeSystem="2.16.840.1.113883.6.1"
displayName="NA" />
<observationEventTime low="20110803" high="20110803" />
<observationValue>
<physicalQuantity value="140" unit="meq/l" />
</observationValue>
<interpretation code="N" codeSystem="2.16.840.1.113883.5.83" />
</observationResult>
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.31" /> <!-- Result observation template -->
<id root="57968a4a-0167-4494-a110-ffe276c8e62b" />
<observationFocus code="2823-3" codeSystem="2.16.840.1.113883.6.1"
displayName="K" />
<observationEventTime low="20110803" high="20110803" />
<observationValue>
<physicalQuantity value="4.0" unit="meq/l" />
</observationValue>
<interpretation code="N" codeSystem="2.16.840.1.113883.5.83" />
</observationResult>
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.31" /> <!-- Result observation template -->
<id root="6215747f-c61b-4652-8b29-a9b9e2c6509c" />
<observationFocus code="2075-0" codeSystem="2.16.840.1.113883.6.1"
displayName="CL" />
<observationEventTime low="20110803" high="20110803" />
<observationValue>
<physicalQuantity value="102" unit="meq/l" />
</observationValue>
<interpretation code="N" codeSystem="2.16.840.1.113883.5.83" />
</observationResult>
<observationResult>
<templateId root="2.16.840.1.113883.10.20.1.31" /> <!-- Result observation template -->
<id root="287132be-39e2-40bf-bc6c-de09f09ce6f1" />
<observationFocus code="1963-8" codeSystem="2.16.840.1.113883.6.1"
displayName="HCO3" />
<observationEventTime low="20110803" high="20110803" />
<observationValue>
<physicalQuantity value="35" unit="meq/l" />
</observationValue>
<interpretation code="H" codeSystem="2.16.840.1.113883.5.83" />
</observationResult>
</observationResults>
<!-- current medications -->
<substanceAdministrationEvents>
<substanceAdministrationEvent>
<id root="2.16.840.1.113883.3.795.10.1" extension="4519239" />
<substanceAdministrationGeneralPurpose
codeSystem="2.16.840.1.113883.6.5" codeSystemName="SNOMED CT"
code="18629005" displayName="Administration of drug or medicament" />
<!--<substanceAdministrationGeneralPurpose codeSystem="2.16.840.1.113883.6.5"
codeSystemName="SNOMED CT" code="384810002" displayName="Immunization/vaccination
management (procedure)"/> -->
<substance>
<id root="f4a1d18b-2b92-4399-b4f9-efb1828d267d" />
<!-- Hydrochlorothiazide 25 MG Oral Tablet -->
<substanceCode codeSystem="2.16.840.1.113883.6.88"
code="310798" />
</substance>
<documentationTime low="20110803" high="20110803" />
</substanceAdministrationEvent>
</substanceAdministrationEvents>
</clinicalStatements>
<clinicalStatementRelationships>
<clinicalStatementRelationship>
<sourceId root="33d27883-eb74-11e0-9572-0800200c9a66" />
<targetId root="e814debb-8a47-451b-8f01-f4b7f2beeba1" />
<targetRelationshipToSource codeSystem="2.16.840.1.113883.5.1002"
code="COMP" />
</clinicalStatementRelationship>
<clinicalStatementRelationship>
<sourceId root="33d27883-eb74-11e0-9572-0800200c9a66" />
<targetId root="57968a4a-0167-4494-a110-ffe276c8e62b" />
<targetRelationshipToSource codeSystem="2.16.840.1.113883.5.1002"
code="COMP" />
</clinicalStatementRelationship>
<clinicalStatementRelationship>
<sourceId root="33d27883-eb74-11e0-9572-0800200c9a66" />
<targetId root="6215747f-c61b-4652-8b29-a9b9e2c6509c" />
<targetRelationshipToSource codeSystem="2.16.840.1.113883.5.1002"
code="COMP" />
</clinicalStatementRelationship>
<clinicalStatementRelationship>
<sourceId root="33d27883-eb74-11e0-9572-0800200c9a66" />
<targetId root="287132be-39e2-40bf-bc6c-de09f09ce6f1" />
<targetRelationshipToSource codeSystem="2.16.840.1.113883.5.1002"
code="COMP" />
</clinicalStatementRelationship>
</clinicalStatementRelationships>
<clinicalStatementEntityInRoleRelationships>
<!--here is the lab technician relationship to one of the above labs -->
<clinicalStatementEntityInRoleRelationship>
<clinicalStatementId root="287132be-39e2-40bf-bc6c-de09f09ce6f1" />
<entityId root="71ea2b7d-e6dd-4d72-a8e2-ff69862db52d" />
<role codeSystem="HL7-OID" code="appropriateCode" displayName="Lab Technician" />
</clinicalStatementEntityInRoleRelationship>
</clinicalStatementEntityInRoleRelationships>
<!--<entityRelationships/> -->
<entityLists>
<persons>
<!--this is a lab technician -->
<person>
<id root="71ea2b7d-e6dd-4d72-a8e2-ff69862db52d" />
<name use="C">
<part type="GIV" value="Jane" />
<part type="FAM" value="Doe" />
</name>
<telecom value="tel:801-123-4567" use="WP" />
<telecom value="mailto:jane@lab.com" use="WP" />
</person>
</persons>
</entityLists>
</patient>
</vmrInput>
</in:cdsInput> |
