User Documentation for MDHT Runtime APIs

0
0
31
7 months ago
Preview
Full text
  Revision: Effective Date:  6 11/28/2011 User Documentation  Author: Allyson Weaver Bunker  for MDHT Rama Ramakrishnan   Runtime APIs  User Documentation for MDHT Runtime APIs Document History Revision History Revision Number Revision Date Summary of Changes Author   1 4/13/2011 Allyson Weaver Bunker 2 4/15/2011 Content Development/ Examples  Allyson Weaver Bunker 3 5/9/2011 Formatting Allyson Weaver Bunker 4 7/27/2011 Content modifications Rama Ramakrishnan 5 8/16/2011 Updates to the Façade API Rama Ramakrishnan 6 11/28/2011 Updated MDHT Logo Allyson Weaver Bunker  User Documentation for MDHT Runtime APIs Table of Contents   1. Introduction............................................................................................................. 7  2. Environment Set Up................................................................................................ 8  2.1. Instructions for Installation..........................................................................................................8  2.2. MDHT APIs................................................................................................................................8  2.3. Patterns .....................................................................................................................................9  3. Using APIs............................................................................................................ 11  3.1. Produce ...................................................................................................................................11  3.2. Consume .................................................................................................................................19  3.3. Validate ...................................................................................................................................22  3.4. Utility/Convenience ..................................................................................................................23 Using Facade API [ DRAFT ] .............................................................................................................26  Appendix A. Creating the MDHT Runtime Library ....................................................... 28  User Documentation for MDHT Runtime APIs Table of Figures  Figure 1 – API Levels.................................................................................................................................... 8 Figure 2 – Produce-CDA Document ............................................................................................................ 11 Figure 3 – Creating Document Instance ...................................................................................................... 12 Figure 4 – Creating Problem Act ................................................................................................................. 13 Figure 5 – Creating Alert Observation ......................................................................................................... 13 Figure 6 – Creating Playing Entity ............................................................................................................... 14 Figure 7 – Creating Reaction Observation................................................................................................... 15 Figure 8 – Creating Alert Status .................................................................................................................. 16 Figure 9 – Serializing the Document to XML................................................................................................ 16 Figure 10 – Obtaining alerts from Document ............................................................................................... 20 Figure 11 – Getting Reaction Observations ................................................................................................. 21 Figure 12 – Validate- Using general API’s to validate instance against constraints....................................... 22 Figure 13 – Using Domain Specific Java API............................................................................................... 23 Figure 14 – Exporting Menu ........................................................................................................................ 28 Figure 15 – Plug In Selection ...................................................................................................................... 29 Figure 16 – Destination Location ................................................................................................................. 30  User Documentation for MDHT Runtime APIs Figures Referenced  3.2.0 Consume-Extracting Data  3.4.3 OCL Support  3.4.2 Domain Specific Java API  3.4.1 Utility Convenience  3.3.1 Validate Onload  3.2.7 Getting reaction observations 3.3.0 Validate- Using general API’s to validate instance against constraints in the model.  3.2.6 Discussion about Playing Entity  3.2.5 Getting Coded Value  3.2.4 Looping over problem acts  3.2.3 Obtaining alerts from Document  3.2.2 Loading Document from File  3.2.1 Static Package Demonstration  3.1.8 Specializing the Document to XML  2.4.0 Exporting Menu  3.1.7 Creating Alert Status  3.1.6 Creating Reaction Observation  3.1.5 Creating Playing Entity  3.1.4 Creating Alert Observation  3.1.3 Creating Problem Act  3.1.2 Creating Alerts section and Narrative Block  3.1.1 Creating Document Instance  3.1.0 Produce-CDA Document  2.5.0 API Levels  2.4.2 Destination Location  2.4.1 Plug In Selection  3.4.4 Query Filter Operations  User Documentation for MDHT Runtime APIs   User Documentation for MDHT Runtime APIs 1. Introduction  This document provides instructions to use the MDHT Java API’s for creating and parsing CDA based documents. An EMR (Electronic Medical Record) system or a EHRS (Electronic Health Record System) stores the patient and related healthcare information in a proprietary format. In order to create / translate the information from a standard document like the CDA (Clinical Document Architecture), a deep knowledge of the internal details of the standards are a pre- requisite. MDHT Java API’s can help bridge the gap in this transformation to / from a standard CDA based document. By using an ‘Adapter’ pattern, the transformations to / from the CDA can be accomplished, with minimal knowledge of the CDA standard.  An adapter for an EMR / EHR system can accommodate the following:  1. Imports CDA documents into the EMR / EHR system and extracts information from the documents.  2. Extracts data from the EMR / EHR system to create a CDA document.  User Documentation for MDHT Runtime APIs Java Platform APIs Core Technology APIs (EMF, OCL)2. Environment Set UpDownload the latest MDHT Runtime API library zip file from the following URL :Extract the zip file to the local drive ( C:\mdht_runtime)Within your preferred IDE environment, add the extracted files to the project classpath.  Base Model APIs (CDA, Datatypes, Vocab, RIM) Continuity of Care Document (CCD) APIs  IHE Patient Care Coordination (PCC) APIs HITSP C32, C83 APIs  This section provides reference for setting up an environment for using the pre-built MDHT Java API’s for transforming CDA based documents.  2.1. Instructions for Installation   http://sourceforge.net/projects/oht-modeling/files/Runtime/ . ( The zip file as of this document is org.openhealthtools.mdht.uml.cda.runtime_1.0.0.201106171356.zip )  o For an Eclipse based project do the following , Right Click on the Project -> Select Properties menu option -> Select Java Build Path on the left side pane -> Select the tab Libraries -> Select button Add External Jars.. )  2.2. MDHT APIs   API’s delivered by the MDHT Runtime API Jars can be divided into three different levels. Each level builds upon the other. API’s are an artifact that get generated or delivered by MDHT. You don’t need the user interface to be installed to be able to see the runtime API’s.  Figure 1 – API Levels  Higher Level Low Level  Base Level  User Documentation for MDHT Runtime APIs API Descriptions Low-level Technology APIs   These APIs come from the technology decisions made by the MDHT project. MDHT is based on Eclipse and the Eclipse Modeling Framework. APIs at this level are related to the underlying EMF model and allow the programmer to manipulate EMF objects in a uniform way and access metamodel information (e.g. EClasses, EAnnotations, etc.). Typically, client code would not use the low-level APIs directly, however, there are certain circumstances where the EMF reflection API is useful.  Generated CDA Base Model APIs   The base model APIs are generated from the MDHT base models for CDA. This includes HL7 CDA R2, HL7 Datatypes R1, HL7 Vocabulary and HL7 RIM. MDHT uses class inheritance in the CDA template models. All methods defined at this level are inherited and available at higher levels. For example, a convenience method “addSection” has been added to the ClinicalDocument class. This method can be used to add a Section object directly to a ClinicalDocument object (without going through component.structuredBody.component).  This method is available in all subclasses of ClinicalDocument (e.g. ContinuityOfCareDocument and HITSP PatientSummary).  Generated CDA Template Model APIs   This APIs, exist (logically) at a higher level in the stack as they are built on top of the APIs below them. They typically include domain-specific class names that follow the CDA templates that they represent (e.g. CCD ProblemAct, HITSP Condition). They also include “getter” methods to access subordinate templates. For example, if a document-level template has an association to a section-level template in the model, then a “getter’ method for the section-level template exists in the document-level template class.  Utility / Convenience APIs   There are additional Utility APIs that facilitate the process of producing, consuming and validating CDA documents. The CDAUtil class contains load/save/validate methods, a Query/Filter API, OCL check/query and a CDAXPath adapter API. The details of these APIs will be discussed later in the document.2.3. Patterns  Patterns used in the document are important to notice. There will be patterns that are dictated by the technology. This determines the way the generated code looks and how the API’s are used to produce, consume and validate CDA documents.  Interface/Implementation Classes   For every class defined in a CDA template UML model, there is a Java interface and Java implementation class generated. For example, the ContinuityOfCareDocument class becomes ContinuityOfCareDocument interface and ContinuityOfCareDocumentImpl class. Any client code that needs to use the ContinuityOfCareDocument will do so via the ContinuityOfCareDocument interface.  User Documentation for MDHT Runtime APIs Singleton Factory Class to Create Instances   In order to create an instance of a class, client code must do so via a singleton factory class. Each CDA template model generates an EMF Package which corresponds to a set of generated Java packages. Each EMF Package also gets a singleton Factory class to create instances of classes in that package. ContinuityOfCareDocument ccdDocument = CCDFactory.eINSTANCE.createContinuityOfCareDocument().init(); // create an initialize an instance of ContinuityOfCareDocument This pattern applies to the generated base model APIs as well as the CDA template model APIs. In this example above, there is an additional method call to init(). This method is called to initialize the object where all default/fixed values get automatically populated. This reduces the amount of code necessary to create a conformant object. The init() method is only found in the generated CDA template model APIs  EMF Package Registration for Deserialization   In order to deserialize a CDA document into the appropriate template classes based on template identifiers in the template instance, EMF Package Registry needs to know what models exist in the environment. When using MDHT in standalone Java applications, the generated singleton Package class must but “touched” once at the beginning of the code: CCDPackage.eINSTANCE.eClass(); // static package registration In this example, we are telling the EMF Package registry that we have CCD (and all of it’s dependent) models available in the environment. If the deserializer encounters a template id from CCD, it will deserialize that part of the XML instance into the template class that corresponds to that template id.  User Documentation for MDHT Runtime APIs 3. Using APIs3.1. Produce  1. Produce: GOAL Write/produce/construct a CDA document - Using the APIs to programmatically construct an instance. When someone needs to produce an instance they have clinical data and want to get it into CDA format. They will use Java APIs to programmatically construct a CDA in XML format.  Figure 2 – Produce-CDA Document // create and initialize an instance of the ContinuityOfCareDocument class  ContinuityOfCareDocument ccdDocument = CCDFactory. eINSTANCE .createContinuityOfCareDocument().init();  // create a patient role object and add it to the document  PatientRole patientRole = CDAFactory. eINSTANCE .createPatientRole(); ccdDocument.addPatientRole(patientRole);  II id = DatatypesFactory. eINSTANCE .createII(); patientRole.getIds().add(id); id.setRoot( "996-756-495" ); id.setExtension( "2.16.840.1.113883.19.5" );  // create an address object and add it to patient role  AD addr = DatatypesFactory. .createAD();  eINSTANCE  patientRole.getAddrs().add(addr); addr.getUses().add(PostalAddressUse. H ); addr.addStreetAddressLine( "1313 Mockingbird Lane" ); addr.addCity( "Janesville" ); addr.addState( "WI" ); addr.addPostalCode( "53545" );  // create a patient object and add it to patient role  Patient patient = CDAFactory. .createPatient();  eINSTANCE  patientRole.setPatient(patient); PN name = DatatypesFactory. eINSTANCE .createPN(); patient.getNames().add(name); name.addGiven( "Henry" ); name.addFamily( "Levin" ); CE administrativeGenderCode = DatatypesFactory. eINSTANCE .createCE();  User Documentation for MDHT Runtime APIs   patient.setAdministrativeGenderCode(administrativeGenderCode); administrativeGenderCode.setCode( "M" ); administrativeGenderCode.setCodeSystem( "2.16.840.1.113883.5.1" ); TS birthTime = DatatypesFactory. .createTS();  eINSTANCE  patient.setBirthTime(birthTime); birthTime.setValue( "19320924" ); [Discussion about creating document instance] In this example, we are creating the ContinuityOfCareDocument object using the generated CCD template model API. The first line of code uses the Factory method pattern discussed in Section 2.6 to create an instance of the ContinuityOfCareDocument class. In the same line, there is a call to the init() method which initializes the object with default/fixed values present in the model. For example, the template identifier is always fixed for the CCD document-level template. Therefore, it is auto-populated by the call to the init() method. Figure xx also shows the creation of the PatientRole and Patient objects. These are created using the CDAFactory class from the generated CDA base model API. Attributes of the objects are created using the HL7 Datatypes base model API. For example, the administrative gender code is created and added to the patient object.  Figure 3 – Creating Document Instance // create and initialize the CCD alerts section  AlertsSection alertsSection = CCDFactory. eINSTANCE .createAlertsSection().init(); ccdDocument.addSection(alertsSection);  // set up the narrative (human-readable) text portion of the alerts section  StringBuffer buffer = new StringBuffer(); buffer.append( "<table border=\"1\" width=\"100%\">" ); buffer.append( "<thead>" ); buffer.append( "<tr>" ); buffer.append( "<th>Substance</th>" ); buffer.append( "<th>Reaction</th>" ); buffer.append( "<th>Status</th>" ); buffer.append( "</tr>" ); buffer.append( "</thead>" ); buffer.append( "<tbody>" ); buffer.append( "<tr>" ); buffer.append( "<td>Penicillin</td>" ); buffer.append( "<td>Hives</td>" ); buffer.append( "<td>Active</td>" ); buffer.append( "</tr>" ); buffer.append( "</tbody>" );  User Documentation for MDHT Runtime APIs   buffer.append( "</table>" ); alertsSection.createStrucDocText(buffer.toString()); [Discussion about creating alerts section and narrative block] Next we create the CCD Alerts Section also using the CCD API and add it to the document using a convenience method named addSection from the ClinicalDocument class. This method will create the intermediate objects (component, structuredBody, component) required to add a section. Once the alert section is created, we must create the narrative block portion of the document. In CDA, this is HTML-like markup that captures the human-readable portion of the document. Typically it is this portion which is rendered in web browser using a stylesheet. MDHT treats the narrative text as an opaque chunk of XML. Therefore it must be constructed as such. In the example, we build up the narrative block using a Java StringBuffer and then use it to construct the narrative block with a call to createSrucDocText.  Figure 4 – Creating Problem Act // create and initialize a CCD problem act  ProblemAct problemAct = CCDFactory. eINSTANCE .createProblemAct().init(); alertsSection.addAct(problemAct); id = DatatypesFactory. eINSTANCE .createII(); problemAct.getIds().add(id); id.setRoot(UUID.randomUUID().toString()); [Discussion about creating problem act] The Alert Section contains an enclosing problem act entry which we create using the CCDFactory as seen in Figure xx. We also add an id to the problem act using the Datatypes API and Java utility class UU(ID.  Figure 5 – Creating Alert Observation // create and initialize an alert observation within the problem act  AlertObservation alertObservation = CCDFactory. .createAlertObservation().init();  eINSTANCE  problemAct.addObservation(alertObservation); ((EntryRelationship) alertObservation.eContainer()).setTypeCode(x_ActRelationshipEntryRelationship.  SU BJ );  id = DatatypesFactory. .createII();  eINSTANCE  User Documentation for MDHT Runtime APIs   alertObservation.getIds().add(id); id.setRoot(UUID.randomUUID().toString()); CD code = DatatypesFactory. eINSTANCE .createCD(); alertObservation.setCode(code); code.setCode( "ASSERTION" ); code.setCodeSystem( "2.16.840.1.113883.5.4" ); CS statusCode = DatatypesFactory. .createCS();  eINSTANCE  alertObservation.setStatusCode(statusCode); statusCode.setCode( "completed" ); CD value = DatatypesFactory. eINSTANCE .createCD(); alertObservation.getValues().add(value); value.setCode( "282100009" ); value.setCodeSystem( "2.16.840.1.113883.6.96" ); value.setDisplayName( "Adverse reaction to substance" ); [Discussion about creating alert observation] An alert observation is then added to the problem act as a subordinate entry using the convenience method addObservation from the CDA ClinicalStatement class. This method will add the intermediate entry relationship object and then the subordinate observation. Because addObservation creates the EntryRelationshp for us, we must go back and set the type code (if necessary) per the model. In this case we want the type code to be SUBJ. Therefore we use the Ecore Reflection API (part of the low-level technology APIs) to get the container of the Alert Observation instance and downcast it to an EntryRelationship object which we then use to the set type code. In Figure xx above, we also create the id, code, statusCode and value attributes using the DatatypesFactory class.  Figure 6 – Creating Playing Entity // playing entity contains coded information on the substance  Participant2 participant = CDAFactory. eINSTANCE .createParticipant2(); alertObservation.getParticipants().add(participant); participant.setTypeCode(ParticipationType. );  CSM  ParticipantRole participantRole = CDAFactory. eINSTANCE .createParticipantRole(); participant.setParticipantRole(participantRole); participantRole.setClassCode(RoleClassRoot. MANU ); PlayingEntity playingEntity = CDAFactory. eINSTANCE .createPlayingEntity(); participantRole.setPlayingEntity(playingEntity); playingEntity.setClassCode(EntityClassRoot. MMAT );  User Documentation for MDHT Runtime APIs   CE playingEntityCode = DatatypesFactory. eINSTANCE .createCE(); playingEntity.setCode(playingEntityCode); playingEntityCode.setCode( "70618" ); playingEntityCode.setCodeSystem( "2.16.840.1.113883.6.88" ); playingEntityCode.setDisplayName( "Penicillin" ); [Discussion about creating playing entity] Next we need to say something about the allergic substance. We do so by using the Playing Entity class.  Playing Entity is nested under Participant and Participant Role – objects that we create using CDAFactory. In Playing Entity, we set the code for Penicillin from RxNorm.  Figure 7 – Creating Reaction Observation // reaction observation contains coded information on the adverse reaction  ReactionObservation reactionObservation = CCDFactory. .createReactionObservation().init();  eINSTANCE  alertObservation.addObservation(reactionObservation); ((EntryRelationship) reactionObservation.eContainer()).setTypeCode(x_ActRelationshipEntryRelationship . MFST ); ((EntryRelationship) reactionObservation.eContainer()).setInversionInd(Boolean. );  TRUE  code = DatatypesFactory. eINSTANCE .createCD(); reactionObservation.setCode(code); code.setCode( "ASSERTION" ); code.setCodeSystem( "2.16.840.1.113883.5.4" ); statusCode = DatatypesFactory. .createCS();  eINSTANCE  reactionObservation.setStatusCode(statusCode); statusCode.setCode( "completed" ); value = DatatypesFactory. eINSTANCE .createCD(); reactionObservation.getValues().add(value); value.setCode( "247472004" ); value.setCodeSystem( "2.16.840.1.113883.6.96" ); value.setDisplayName( "Hives" ); [Discussion about creating reaction observation] The AlertObservation also has a place for conveying reaction information. A Reaction Observation instance is created using CCDFactory and added to alert observation using the addObservation method. Again this  User Documentation for MDHT Runtime APIs   creates the intermediate entry relationship object that we immediately access using ehe eContainer method from Ecore Reflection API to set the type code. We also set the code to ASSERTION the status code to “completed” and the value of the observation to the code for “Hives” from SNOMED.  Figure 8 – Creating Alert Status // alert status contains information about whether allergy is currently active  AlertStatusObservation alertStatusObservation = CCDFactory. .createAlertStatusObservation().init();  eINSTANCE  alertObservation.addObservation(alertStatusObservation); ((EntryRelationship) alertStatusObservation.eContainer()).setTypeCode(x_ActRelationshipEntryRelations hip. );  REFR  CE alertStatusObservationValue = DatatypesFactory. eINSTANCE .createCE(); alertStatusObservation.getValues().add(alertStatusObservationValue); alertStatusObservationValue.setCode( "55561003" ); alertStatusObservationValue.setCodeSystem( "2.16.840.1.113883.6.96" ); alertStatusObservationValue.setDisplayName( "Active" ); [Discussion about creating alert status] Finally, we want to add information about the status of the allergy using Alert Status. This is another clinical statement template from CCD named Alert Status Observation. We create and instance of the Alert Status Observation class using CCDFactory. Then we set the type code in a similar fashion to reaction observation and we set the value to code for “Active” from SNOMED.  // write the document out to the console  CDAUtil.save(ccdDocument, System. );  out  [Discussion about serializing the document to XML] Once we have constructed our document using the various APIs, typically we want to serialize the Java objects to XML. In Figure xx above, we using the CDAUtil class to save the ccdDocument to a Java output stream. In this example, we use System.out which prints the XML representation to the console.  Figure 9 – Serializing the Document to XML  User Documentation for MDHT Runtime APIs   <?xml version="1.0" encoding="UTF-8"?> <ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"> <templateId root="2.16.840.1.113883.10.20.1"/> <code code="34133-9" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Summarization of episode note"/> <recordTarget> <patientRole> <id root="996-756-495" extension="2.16.840.1.113883.19.5"/> <addr use="H"><streetAddressLine>1313 Mockingbird Lane</streetAddressLine><city>Janesville</city><state>WI</state><postalCode>5354 5</postalCode></addr> <patient> <name><given>Henry</given><family>Levin</family></name> <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/> <birthTime value="19320924"/> </patient> </patientRole> </recordTarget> <component> <structuredBody> <component> <section> <templateId root="2.16.840.1.113883.10.20.1.2"/> <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Allergies, adverse reactions, alerts"/> <text><table border="1" width="100%"><thead><tr><th>Substance</th><th>Reaction</th><th>Status</th></tr>< /thead><tbody><tr><td>Penicillin</td><td>Hives</td><td>Active</td></tr></tbody>< /table></text> <entry> <act classCode="ACT" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.1.27"/> <id root="a7140229-4a87-457a-b63e-50b79c57dfa1"/> <code nullFlavor="NA"/> <entryRelationship typeCode="SUBJ"> <observation moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.1.18"/> <id root="85d9039f-d254-4d5b-86d1-7500279f0454"/> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <statusCode code="completed"/> <value xsi:type="CD" code="282100009" codeSystem="2.16.840.1.113883.6.96" displayName="Adverse reaction to substance"/> <participant typeCode="CSM"> <participantRole classCode="MANU"> <playingEntity classCode="MMAT">  User Documentation for MDHT Runtime APIs   <code code="70618" codeSystem="2.16.840.1.113883.6.88" displayName="Penicillin"/> </playingEntity> </participantRole> </participant> <entryRelationship typeCode="MFST" inversionInd="true"> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.1.54"/> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <statusCode code="completed"/> <value xsi:type="CD" code="247472004" codeSystem="2.16.840.1.113883.6.96" displayName="Hives"/> </observation> </entryRelationship> <entryRelationship typeCode="REFR"> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.1.57"/> <templateId root="2.16.840.1.113883.10.20.1.39"/> <code code="33999-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Status"/> <statusCode code="completed"/> <value xsi:type="CE" code="55561003" codeSystem="2.16.840.1.113883.6.96" displayName="Active"/> </observation> </entryRelationship> </observation> </entryRelationship> </act> </entry> </section> </component> </structuredBody> </component> </ClinicalDocument> [Discussion of XML instance] The XML instance that is serialized is shown in Figure xx above. Note that many of the fixed/default values for the various templates (document, section and entry-level) have been filled in automatically from the model. This reduces the amount of client code necessary to create a conformant instance.  User Documentation for MDHT Runtime APIs 3.2. Consume  1. Consume: Someone sends standard compliance document and needs to extract data and save to the system. Using API’s to extract specific information.  2. Query Filter Operation  // static package registration  CCDPackage. .eClass();  eINSTANCE  [Discussion of static package registration] The first step in reading a CDA document in from a Java input stream is to register the Ecore packages that you want the EMF deserilizer to consider when it converts XML into instances of the appropriate Java classes. In this case, we want the document to be deserialized as a CCD document. Therefore we use this line of codet to statically ppopulate the EPackage.Registry with the CCDPackage instance and the package instances of its dependencies (e.g. CDA, HL7 Datatypes, etc.).  // load sample continuity of care document from file  ContinuityOfCareDocument ccdDocument = (ContinuityOfCareDocument) CDAUtil.load( FileInputStream( "resources/SampleCCDDocument.xml" ));  new  [Discussion of loading document from file] Then we use the CDAUtil class to read the document in from a Java input stream. In this case, we are reading the SampleCCDDocument.xml file that comes with the CCD specification. We can downcast to ContinuityOfCareDocument because we expect that type to be returned (as opposed to a generic instance of the ClinicalDocument class).  // get the alerts section from the document using domain-specific "getter" method  AlertsSection alertsSection = ccdDocument.getAlertsSection(); [Discussion of getting the alerts section from the document]  User Documentation for MDHT Runtime APIs   The domain-specific API that is generated contains getter methods for section and entry-level templates based on associations in the model. In the CCD model, we have an association between the ContinuityOfCareDocument class and the AlertsSection. Therefore a “getter” method is generated named getAlertsSection. The method is a “query” method in that it is read-only and implemented using OCL.  Figure 10 – Obtaining alerts from Document // for each enclosing problem act  (ProblemAct problemAct : alertsSection.getProblemActs()) {  for // look at subordinate observations // we don't have a domain-specific "getter" method here so we use // entry relationship for (EntryRelationship entryRelationship :  problemAct.getEntryRelationships()) {  // check for alert observation if (entryRelationship.getObservation() instanceof AlertObservation) { // see below for details...  }  } } [Discussion of looping over problem acts looking for AlertObservations] The domain-specific method getProblemActs returns all Acts that are also ProblemActs per the CCD model.  We want to loop through these problem acts and process their subordinate observation entries. Due to the structure of the CCD model, we do not have a method named getAlertObservation though this could be implemented manually at design-time. Instead we must iterate over all entry relationships and check to see which ones are Alert Observations using the Java instanceof operator.  // get coded value from alert observation  AlertObservation alertObservation = (AlertObservation) entryRelationship.getObservation(); (!alertObservation.getValues().isEmpty()  if  && alertObservation.getValues().get(0) CD) {  instanceof  CD value = (CD) alertObservation.getValues().get(0);System. out .println( "alert observation value: " + value.getCode() + ", " value.getCodeSystem() + ", " + value.getDisplayName()); }  User Documentation for MDHT Runtime APIs   Discussion about getting the coded value from the alert observation[ Once we have found an Alert Observation instance, we print the value out to the console. The values list is type ANY so it is appropriate to check to make sure it is non-empty and conforms to the correct CD data type. This allows us to downcast and access CD methods (e.g. getCode).  [Discussion about playing entity] Now we access information about the allergic substance. We do this by traversing the participant and participantRole links checking to ensure we have the correct type codes on both before considering the nested playing entity. Once we found a playing entity that matches our criteria, we access the code and print it to the console.  Figure 11 – Getting Reaction Observations // get reaction observations using domain-specific "getter" method  (ReactionObservation reactionObservation :  for  alertObservation.getReactionObservations()) {  if (!reactionObservation.getValues().isEmpty()  && alertObservation.getValues().get(0) CD) {  instanceof  CD value = (CD) reactionObservation.getValues().get(0); System. out .println( "reaction observation value: " + value.getCode() + ",  " + value.getCodeSystem() + ", " + value.getDisplayName());  } [Discussion about getting reaction observations] We can use a domain-specific method named getReactionObservations to get the reaction observations from an alert observation. Iterating over the reaction observations, we process the value ensuring that we test for non-empty and the expected data type (CD).  // get alert status observation using domain-specific "getter" method  AlertStatusObservation alertStatusObservation = alertObservation.getAlertStatusObservation(); (alertStatusObservation != &&  if null  !alertStatusObservation.getValues().isEmpty() && alertObservation.getValues().get(0) instanceof CD) { CD value = (CD) alertStatusObservation.getValues().get(0); System. .println( "alert status observation value: " + value.getCode() + ",  out  User Documentation for MDHT Runtime APIs " + value.getCodeSystem() + ", " + value.getDisplayName());  } [Discussion about getting alert status observation] The last piece of information we want from the alert observation is status information. We can use getAlertStatusObservation to get the current status of the allergy. This follows a similar pattern to the reaction observation example.3.3. Validate 1. Upfront discussion of how EMF does validation.  Validate: Using general API’s to validate instance against constraints in the model.  Figure 12 – Validate- Using general API’s to validate instance against constraints // static package registration  CCDPackage. .eClass();  eINSTANCE // validate on load // create validation result to hold diagnostics  ValidationResult result = new ValidationResult(); ContinuityOfCareDocument ccdDocument = (ContinuityOfCareDocument) CDAUtil.load( new FileInputStream( "resources/SampleCCDDocument.xml" ), result);  for (Diagnostic diagnostic : result.getWarningDiagnostics()) {  System. out .println(diagnostic.getMessage()); } [Discussion about validate-on-load] Figure xx above, illustrates how to load a CCD document from a Java input stream and perform validation on the document during the load process. There are two types of validation at work. Schema validation takes place on a DOM-based representation of the document to ensure the document is conformant to the base CDA standard. The results of schema validation are stored in the validation result object. Then the EMF deserializer converts the DOM-based representation into an EMF representation. After conversion, EMF validation is performed. This ensures the EMF-based representation is conformant to the constraints defined in the template model. These two types of validation are used together to achieve complete validation.  Different Validators process the content tree and produce diagnostics. Diagnostics contain information about a constraint that was violated. This includes severity, source, target and message. Severity of the constraint  User Documentation for MDHT Runtime APIs   violation is one of ERROR, WARNING or INFO. Source is the fully-qualified name of the Validator that produced the diagnostic. Target is the object being validated. Message is a human-readable informational message related to the constraint that was violated. Typically this would be in the form of a structured English conformance statement such as: CCD Medication Activity SHOULD satisfy: Contains exactly one doseQuantity or rateQuantity. (CONF-311)  // validation on clinical document object  CDAUtil.validate(ccdDocument, BasicValidationHandler() {  new public void handleError(Diagnostic diagnostic) {  System. out .println( "ERROR: " + diagnostic.getMessage()); }  public void handleWarning(Diagnostic diagnostic) {  System. out .println( "WARNING: " + diagnostic.getMessage()); }  }); [Discussion about validation on clinical document object] Another option is to validate a clinical document object after it has been deserialized. This will check the document against IG-specific constraints defined in the template model and will check partial base schema conformance. The BasicValidationHandler class allows the developer to implement which diagnostics to respond to by overriding the handleError, handleWarning and handleInfo methods.3.4. Utility/Convenience1. Another case of API’s is separate from the general model code. CDA utilities have numerous methods.  Figure 13 – Using Domain Specific Java API // static package registration  CCDPackage. .eClass();  eINSTANCE  User Documentation for MDHT Runtime APIs // load sample CCD document  ContinuityOfCareDocument ccdDocument = (ContinuityOfCareDocument) CDAUtil.load( new FileInputStream( "resources/SampleCCDDocument.xml" )); System. out .println(ccdDocument); CDAUtil.save(ccdDocument, System. );  out // 1. Using the generated, domain-specific Java API  System. .println( "\nUsing the generated, domain-specific Java API" );  out  AdvanceDirectivesSection section = ccdDocument.getAdvanceDirectivesSection(); System. out .println(section); List<AdvanceDirectiveObservation> observations = section.getAdvanceDirectiveObservations(); System. out .println(observations); [Discussion about using the generated, domain-specific Java API] In Section 3.2, we showed how generated, domain-specific Java APIs can be used to access parts of the CDA document. In this example, we will compare this approach with 3 other approaches. Figure xx above, shows a sample CCD document being loaded into memory and the domain-specific methods getAdvanceDirectivesSection and getAdvanceDirectiveObservations used to access those portions of the document.  // 2. Using CDAUtil OCL Support (for OCL gurus)  System. out .println( "\nUsing CDAUtil OCL Support (for OCL gurus)" ); section = (AdvanceDirectivesSection) CDAUtil.query(ccdDocument,  "self.getAllSections()->select(sect : cda::Section | sect.oclIsKindOf(ccd::AdvanceDirectivesSection))->asSequence()- >first().oclAsType(ccd::AdvanceDirectivesSection)" );  System. .println(section);  out  observations = new ArrayList<AdvanceDirectiveObservation>( (Collection<AdvanceDirectiveObservation>) CDAUtil.query(section,  "self.getObservations()->select(obs : cda::Observation | obs.oclIsKindOf(ccd::AdvanceDirectiveObservation))- >collect(oclAsType(ccd::AdvanceDirectiveObservation))" ));  System. .println(observations);  out  [Discussion about using OCL support] There is support to evaluate OCL query expressions against the in-memory EMF representation. In Figure xx above, we are using OCL queries to access the same information.  User Documentation for MDHT Runtime APIs // 3. Using CDAUtil Query/Filter Operations (programmatic access for // Java gurus)  System. out .println( "\nUsing CDAUtil Query/Filter Operations (programmatic access  for Java gurus)" );  Query query = new Query(ccdDocument); section = query.getSection(AdvanceDirectivesSection. );  class  System. .println(section);  out  observations = query.getClinicalStatements(AdvanceDirectiveObservation. class ); System. out .println(observations); [Discussion about using Query/Filter operations] CDAUtil also contains a query/filter mechanism that aggregates parts of the document and then filters them by type and/or user-defined filters. In the example (Figure xx) above, we are filtering document sections by type and filtering observations by type.  // 4. Using CDAUtil CDA XPath Support (for XML gurus)  System. .println( "\nUsing CDAUtil CDA XPath Support (for XML gurus)" );  out  CDAXPath xpath = new CDAXPath(ccdDocument); section = xpath.selectSingleNode(  "//cda:section[cda:templateId[@root='2.16.840.1.113883.10.20.1.1']]" ,  AdvanceDirectivesSection. class ); System. out .println(section); observations = xpath.selectNodes(  "//cda:observation[cda:templateId[@root='2.16.840.1.113883.10.20.1.17']]" ,  AdvanceDirectiveObservation. );  class  System. .println(observations);  out  [Discussion about using CDA XPath support] Finally, we have an XPath adapter that allows the user to query the document using XPath expressions. The relationship between DOM nodes and EMF objects is stored allowing for access to both representations as the result of an XPath query.  User Documentation for MDHT Runtime APIs Using Facade API [ DRAFT ] Note : These API are currently not bundled with the Runtime API library.   By using the Façade API, the user is shielded from creating instances of the underlying CCD / IHE / HITSP constructs. As illustrated in the example below, a new façade interface for PatientSummary, enables the user to get the various section details populated without individually instantiating the corresponding components and orchestrating them together.  The façade API’s are packaged separately from the core apis. The façade API for the HITSP component is assembled in the org.openhealthtools.mdht.uml.cda.hitsp.facade jar file. The API’s are contained in org.openhealthtools.mdht.uml.cda.hitsp.domain package. // Create the Patient Summary instance from the HITSPFactory. PatientSummary patientSummaryImpl = HITSPFactory. .createPatientSummary().init();  eINSTANCE // Create the Patient Summary façade instance handle.  // Note the use of the DomainFactory, which corresponds to the façade.  IPatientSummary patientSummary = IDomainFactory. .createPatientSummary();  eINSTANCE  // Set the appropriate document type in the facade patientSummary.setCDAType(patientSummaryImpl); // From this point , the Façade operations can be used to modify the base object. // For example, To set the ProblemList, use the façade operation withProblemListSection(). This operation will instantiate a ProblemList Section and attach to the PatientSummary.  IProblemListSection problemListSection = patientSummary.withProblemListSection(); // Similarly, for setting a section PregnancyHistorySection, use the façade operation withPregnancyHistorySection(). Note that this section is sourced from a  IHE template. But the user is shielded from these details.  patientSummary.withPregnancyHistorySection();   User Documentation for MDHT Runtime APIs   Yet, another advantage of the façade could be effected, when using business names, that are different from those defined in the base components. In the HITSP C48 specification, a content module ‘Resolved Problems’ refers to HITSP/C83 Section 2.2.1.4 History of Past Illness . In the Discharge Summary implementation for the ToC (Transfer Of Care) initiative, the façade for DischargeSummary references the ‘History Of Past Illness’, via the content module name. // Create the Discharge Summary instance from the HITSPFactory. DischargeSummary dischargeSummaryImpl = HITSPFactory.eINSTANCE.createDischargeSummary().init(); // Create the Discharge Summary façade instance handle.  IDischargeSummary dischargeSummary =  IDomainFactory.eINSTANCE.createDischargeSummary(); // Set the appropriate document type in the facade dischargeSummary.setCDAType(dischargeSummaryImpl); // To set the History of Past Illness, use the façade operation withResolvedProblems() dischargeSummary. withResolvedProblems();  User Documentation for MDHT Runtime APIs Appendix A. Creating the MDHT Runtime Library   This describes the steps for creating the java libraries from the MDHT models and packaging them up with the set of EMF and OCL run-time dependency libraries that are needed to provide a basic runtime library for using MDHT artifacts.  1. Open the MDHT Workspace containing the models for which the run-time environment is needed.  2. Right-click on one of the projects and select "Export…" from the menu.  Figure 14 – Exporting Menu  3. Expand the "Plug-in Development" folder 4. Select "Deployable plug-ins and fragments" and then click on "Next".  User Documentation for MDHT Runtime APIs Figure 15 – Plug In Selection  5. Select the projects that are to be exported as jar files… If doing all of the current ones then select the following: a. org.openhealthtools.mdht.uml.cda  b. org.openhealthtools.mdht.uml.cda.ccd  c. org.openhealthtools.mdht.uml.cda.cdt  d. org.openhealthtools.mdht.uml.cda.consol  e. org.openhealthtools.mdht.uml.cda.hitsp  f. org.openhealthtools.mdht.uml.cda.ihe  g. org.openhealthtools.mdht.uml.cda.rim  h. org.openhealthtools.mdht.uml.cda.vocab i. org.openhealthtools.mdht.uml.hl7.datatypes  User Documentation for MDHT Runtime APIs 6. Enter a directory for where to place the jar files on the "Destination" tab.  Figure 16 – Destination Location  Under the Options tab, check the option ‘Qualifier Replacement’ Click on "Finish"  7. This will create a jar file for each of the libraries in the location you specified. The current naming of the jar files will be <project-name>_<version>.<timestamp>.jar  User Documentation for MDHT Runtime APIs   8. Once the libraries are generated for the MDHT models, you will need some additional eclipse libraries in order to use these generated libraries. These libraries can be found in the eclipse environment. If you are using the all-in-one download, then these will be in the eclipse\plugins folder. The following is the list of libraries that are needed: a. lpg.runtime.java_2.0.17.v201004271640.jar (NOTE: for Eclipse 3.5.x the OCL parser runtime library may be net.sourceforge.lpg.lpgjavaruntime_1.1.0.v200803061910.jar) b. org.eclipse.emf.common_2.6.0.v20100914-1218.jar  c. org.eclipse.emf.ecore_2.6.1.v20100914-1218.jar  d. org.eclipse.emf.ecore.xmi_2.5.0.v20100521-1846.jar  e. org.eclipse.ocl_3.0.1.R30x_v201008251030.jar  f. org.eclipse.ocl.ecore_3.0.1.R30x_v201008251030.jar

RECENT ACTIVITIES

Etiquetas

Documento similar

Framework for Success in Postsecondary Writing
0
0
16
Electoral Systems and Real Prices: Panel Evidence for the OECD
0
0
36
Conventional versus modern abattoirs in Colombia: Impacts on welfare indicators and risk factors for high muscle pH in commercial Zebu young bulls
0
0
9
Recommendations for the Regionalizing of Coffee Cultivation in Colombia: A Methodological Proposal Based on Agro- Climatic Indices
0
0
22
Optimization of the HS-SPME Technique by using Response Surface Methodology for Evaluating Chlorine Disinfection by-Products by GC in Drinking Water
0
0
7
Filed 030717 for the Period Ending 123116
0
0
127
COGNICIÓN, JUEGO Y APRENDIZAJE: UNA PROPUESTA PARA EL AULA DE LA PRIMERA INFANCIA Cognition, play and learning: a proposal for the early childhood classroom Cognição, Jogo e Aprendizagem: uma proposta para aulas na primeira infância María Francisca Muñoz
0
0
16
WHO Guide for Effective Programmes
0
0
51
The Conceptual Framework for General Purpose Financial Reporting by Public Sector Entities
0
0
121
Factors to be considered in assesing a country’s readiness for dollarization (Nouriel Roubini)
0
0
10
Installation for Windows XP
0
0
22
Challenging Poverty, Vulnerability and Social Exclusion in Nicaragua: Some Considerations for Poverty Reduction Strategies
0
0
32
UV-visible spectroscopy as an alterna- tive to liquid chromatography as analysis method for dissolution testing
0
0
8
Iron(II)-phthalocyanine as a novel recognition sensor for selective potentiometric determination of diclofenac and warfarin drugs
0
0
7
Research Paper Improved Protocol and Data Analysis for Accelerated Shelf-Life Estimation of Solid Dosage Forms
0
0
11
Show more