CONNECT: Release 2.3 Webinar January 19, 2010. CONNECT Architecture Overview Les Westberg 2.
-
Upload
ginger-smith -
Category
Documents
-
view
220 -
download
0
Transcript of CONNECT: Release 2.3 Webinar January 19, 2010. CONNECT Architecture Overview Les Westberg 2.
CONNECT:Release 2.3 Webinar
January 19, 2010
CONNECT Architecture Overview
Les Westberg
2
CONNECT ArchitectureMessage from NHIN
3
PatientDiscovery
MPI Query forDocuments
RetrieveDocuments
Policy SubscriptionManagement
NotificationProcessing
AuditReporting
Patient Discovery
Query forDocuments
RetrieveDocuments
UDDI UpdateManagement
SubscriptionManagement
NotificationProcessing
AuditReporting
NHINNHINCONNECT Components
Customizable Components
Replaceable Components
CONNECT AdapterCONNECT Adapter
Do
cum
ent
Rep
osito
ryD
ocu
men
t R
epo
sitory
SDK ServicesSDK Services
Data Transforms
Data Transforms
Terminology Services
Terminology Services
OthersOthersOthersOthers
Do
cum
ent
Reg
istryD
ocu
men
t R
egistry
MP
IM
PI
Po
licyE
ng
ine
Po
licyE
ng
ine
Su
bscrip
tion
R
epo
sitory
Su
bscrip
tion
R
epo
sitory
Re-
Iden
tification
Re-
Iden
tification
Adapter Service Bus
CONNECT GatewayCONNECT Gateway
NHIN Orchestration ComponentsNHIN Orchestration Components
CONNECT Core ComponentsCONNECT Core Components
Patient DiscoveryPatient
DiscoveryQuery for
DocumentsQuery for
DocumentsRetrieve
DocumentsRetrieve
DocumentsSubscription ManagementSubscription Management
Notification Processing
Notification Processing
AuditReporting
AuditReporting
UDDI Update ManagementUDDI Update Management
Patient Correlation Repository
Patient Correlation Repository
Audit Repository
Audit Repository
Document Cache
Document Cache
Connection Manager
Connection Manager
Subscription Repository
Subscription Repository
OthersOthersOthersOthers
CONNECT ArchitectureMessage to NHIN
4
CONNECT AdapterCONNECT Adapter
Entity Integration SoftwareEntity Integration Software
CONNECT GatewayCONNECT Gateway
Message Proxy ComponentsMessage Proxy Components
CONNECT Core ComponentsCONNECT Core Components
Patient DiscoveryPatient
DiscoveryQuery for
DocumentsQuery for
DocumentsRetrieve
DocumentsRetrieve
DocumentsSubscription ManagementSubscription Management
Notification Processing
Notification Processing
AuditReporting
AuditReporting
Patient Correlation Repository
Patient Correlation Repository
Audit Repository
Audit Repository
Document Cache
Document Cache
Subscription Repository
Subscription Repository
UDDI Update ManagementUDDI Update Management
OthersOthersOthersOthers
SDK ServicesSDK Services
Data Transforms
Data Transforms
Terminology Services
Terminology Services
OthersOthersOthersOthers
PatientDiscovery
Query forDocuments
RetrieveDocuments
SubscriptionManagement
NotificationProcessing
AuditReporting
CONNECT Components
Customizable Components
Replaceable Components
Entity Orchestration ComponentsEntity Orchestration Components
Patient DiscoveryPatient
DiscoveryQuery for
DocumentsQuery for
DocumentsRetrieve
DocumentsRetrieve
DocumentsSubscription ManagementSubscription Management
Notification Processing
Notification Processing
AuditReporting
AuditReporting
Connection Manager
Connection Manager
NHINNHIN
PatientCorrelation
PatientDiscovery
Query forDocuments
RetrieveDocuments
NotificationProcessing
AuditReporting
NotificationProcessing
PassThrough
Orchestrated vs. Pass Through Mode
5
Adapter InterfacePass-Through
Adapter InterfacePass-Through
NHIN Message Receiver
NHIN Message Receiver
CHOICE OF PATH BASED ON CONFIGURATION
Internal NHIN Message Orchestrator
Internal NHIN Message Orchestrator
CONNECT Development Environment
Version 2.1
6
Item Version
Java JRE/JDK 1.6 Update 16
GlassFish 2.1.1
NetBeans 6.7.1
Metro 1.5
MySQL 5.1.41
SoapUI 3.0.1
Major Changes in 2.3
• Support of the Updated NHIN Specs:
– Access Consent
– Audit Query
– Authorization Framework
– Document Query / Document Retrieve
– GIPSE Profile
– Patient Discovery (replaces Subject Discovery)
• FIPS Compliance integrated 2.3 Baseline
• Migration towards [App Server – Platform Independence] using JBOSS
• Improvements to the Continuous Integration Process.
7
Support of the Updated NHIN Specifications
Access Consent
Les Westberg
8
Summary of Changes
• Fine-grained policy document stored as XACML
– Previously it was CDA wrapping XACML
• Storage/Retrieval of PDF Consent Documents
– AdapterPIP interface modified
• Added “Query by Event” support to Document Query
• Changed document registry meta-data to conform to latest NHIN specification
• Removed HIEM notification of access consent documents
• Updated SAML assertions which identify remote access consent documents
• Creation of XSPA XACML to be sent to Policy Decision Point (PDP)
9
Things to be Aware Of
• Fine-grained policy changes were made only to storage and retrieval functions – not to the policy decision point (PDP)
• Redaction has not been implemented yet
• CPP GUI is not supported under Release 2.3
– SoapUI test used to store and retrieve Access Consent documents
• AdapterPIP-soapui-project.xml
• Custom XACML still used between gateway and adapter
– Transformed to XSPA XACML by the Policy Enforcement Point (PEP)
• XSPA support limited to current OASIS specification
– Authorization framework fields which are not defined in XSPA are not sent to PDP
10
Support of the Updated NHIN Specifications
Audit Query
Visu Patlolla
11
Audit Query
NHIN Specification:• Audit Log Query Specification Version 1.3.1 Dated: 02/03/2009
Underlying Specifications:• HITSP/TP15 Collect and Communicate Security Audit Trail Transaction
Version 1.4, July 8, 2009
• IHE ITI TF Revision 5.0 Vol 1& 2 2008-12-12
• IHE IT Infrastructure Technical Framework Supplement 2007-2008: Cross-Enterprise Document Sharing-b (XDS.b)
• IHE IT Infrastructure Technical Framework Supplement 2007-2008: Cross Community Access XC
12
Audit Query
Incorrect Namespace in Audit Query WSDL
• The version of the Nhin Audit Query WSDL used by the CONNECT Gateway did not use the correct Target Namespace from NHIN. Changes were made to the NhinAuditLogQuery.wsdl file to use http://services.nhin.com instead of http://services.nhin.com/wsdl/auditlogquery
• NhincAuditQueryEJB, EntityAuditLogQueryEJB, and NhinAuditQueryProxyImpl NetBean projects updated as appropriate
13
Support of the Updated NHIN Specifications
Authorization Framework
Victoria Vickers
14
Baseline Authorization Framework
Purpose of the Authorization Framework Specification
• Defines the structure of the SAML header for cross enterprise messages
• Defines the NHIN specific attributes
Underlying Specifications
• Assertions and Protocols for the OASIS Security Assertion Markup Language(SAML) V2.0
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
• Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare Version 1.0
http://docs.oasis-open.org/security/xspa/v1.0/saml-xspa-1.0.pdf
15
Focus of Modifications in Release 2.3New NHIN Attributes
New Attribute Statement Attributes
• Home Community ID Attribute
– Provides the Home Communityinitiating the request
– OID format of the NHIE
– Example - urn:oid:2.16.840.1.113883.3.190
• Patient Identifier Attribute
– The patient as identified in therequesting organization
– OID for the assigning authority and the identifier of the patient within thatassigning authority
– Example – 543797436^^^&1.2.840.113619.6.197&ISO
New Authorization Decision Statement Attributes
• The “ContentReference”, “ContentType”, and “Content” attributes from the Trial Implementation specifications have been removed and should no longer be used
• AccessConsentPolicy Attribute
– NameFormat “http://www.hhs.gov/healthit/nhin”
– Value is the OID of the access policies that the asserting entity has previously agreed to
– Example - urn:oid:1.2.3.4
• InstanceAccessConsentPolicy
– NameFormat “http://www.hhs.gov/healthit/nhin”
– Value is the OID of the patient specific access policy instances
– Example - urn:oid:1.2.3.4. 123456789
16
Focus of Modifications in Release 2.3Attribute Statement – Attribute Name
Attribute naming moves toward XSPA profile for SAML
• User Name Attribute: urn:oasis:names:tc:xspa:1.0:subject:subject-id
• User Organization Attribute: urn:oasis:names:tc:xspa:1.0:subject:organization
• Organization ID Attribute: urn:oasis:names:tc:xspa:1.0:subject:organization-id
• Home Community ID Attribute: urn:nhin:names:saml:homeCommunityId
• User Role Attribute: urn:oasis:names:tc:xacml:2.0:subject:role
• Purpose For Use Attribute: urn:oasis:names:tc:xspa:1.0:subject:purposeofuse
• Patient Identifier Attribute: urn:oasis:names:tc:xacml:2.0:resource:resource-id
17
Focus of Modifications in Release 2.3Attribute Statement – Coded Elements
Usage of CE datatype from HL7 v3
• User Role Attribute Value– HL7 namespace - hl7:Role xmlns:hl7="urn:hl7-org:v3“ xsi:type="hl7:CE"
– The code is assigned from SNOMED CT as defined for “NHIN-ROLE”
– The codeSystem is defined to be “2.16.840.1.113883.6.96"
– The codeSystemName is defined to be "SNOMED_CT“
– The displayName shall correlate with the assigned code
• Purpose for Use Attribute– HL7 namespace - hl7:PurposeForUse xmlns:hl7="urn:hl7-org:v3“xsi:type="hl7:CE"
– The code is assigned from Authorization Framework specification
– The codeSystem is defined to be “2.16.840.1.113883.3.18.7.1"
– The codeSystemName is defined to be "nhin-purpose”
– The displayName shall correlate with the assigned code
18
Ins and Outs Authorization Framework Fields
• Transform Assertion Class to/from SAML assertions
• Assertion class fields
– User Name Attribute: Assertion.userInfo.personName(familyName, givenName, secondNameOrInitials)
– User Organization Attribute: Assertion.userInfo.org.name
– Organization ID Attribute: Assertion.userInfo.org.homeCommunityId
– Home Community ID Attribute: Assertion.homeCommunity.homeCommunityId
– User Role Attribute: Assertion.userInfo.roleCoded(code, codeSystem, codeSystemName, displayName)
– Purpose For Use Attribute: Assertion.purposeOfDisclosure(code, codeSystem, codeSystemName, displayName)
– Patient Identifier Attribute: Assertion.uniquePatientId
• Defines XACML Attribute Values for Policy Engine Usage
19
Support of the Updated NHIN Specifications
Document Query / Retrieve
Neil Webb
20
Asynchronous Web service calls tested for Doc Query/Retrieve
CONNECT supports Asynchronous Web service calls.
• The NHIN Specification was updated for Document Query and Document Retrieve to support Asynchronous web service calls by initiating and responding Gateways.
• This was tested and found that the current NHIN Gateway release 2.3 already had capabilities to support Asynchronous Web service calls.
• The test is performed using a JAX-WS Java client project. When a client calls a JAX-WS Web service operation asynchronously, the client does not need to wait for the response to be received.
• The client consumes the web services either through the “polling” or the “callback” approach.
• We used the “callback” approach to test this. The client passes a callback handler during the web service method invocation. The handler’s handleResponse() method is called when the result is available.
21
Support to XDS.b error codes
CONNECT supports various XDS.b error codes
• The NHIN Specification was updated for Document Query and Document Retrieve to support a set of error codes.
• This was tested with a SoapUI project and found that the Gateway is already capable of handling all the error codes mentioned below with out any code modifications.
XDSRegistryError
XDSRegistryBusy
XDSRegistryOutOfResources
XDSTooManyResults
XDSUnknownStoredQuery
XDSStoredQueryMissingParam
XDSStoredQueryParamNumber
Note: Expect for BAD ID, all other error codes are supported by NHIN Gateway. The BAD ID is not directly supported by XDS Registry Services instead we get an XDSRegistryError.
22
Additional Stored Query Support
Document Query Stored Query• Stored query types
– FindDocuments
– FindFolders
– GetAll
– GetDocuments
– GetFolders
– GetAssociations
– GetDocumentsAndAssociations
– GetSubmissionSets
– GetSubmissionSetAndContents
– GetFolderAndContents
– GetFoldersForDocument
– GetRelatedDocuments
• Created SoapUI tests to verify proper handling in the gateway
23
Document Query and Retrieve Audit
Audit Modifications
• Additional Fields– EventID
– EventTypeCode
• Document Query– EventID set to “110112”
– EventTypeCode set to “ITI-18”
• Document Retrieve– EventID set to “110107”
– EventTypeCode set to “ITI-17”
24
Support of the Updated NHIN Specifications
GIPSE Profile
Scott Borst
25
GIPSE Profile
• This is a HIEM profile. The GIPSE Profile specification contains definitions for the following five topics:
• nhin:DeidentifiedPopulationHealthData
• nhin:DeidentifiedPopulationHealthData/Biosurveillance
• nhin:DeidentifiedPopulationHealthData/Biosurveillance/InfluenzaLikeIllness
• nhin:DeidentifiedPopulationHealthData/Biosurveillance/Influenza
• nhin:DeidentifiedPopulationHealthData/Biosurveillance/Pneumonia
• The topics were added to hiemTopicConfiguration.xml and validated using the HIEM services in R2.3 and a small GIPSE file.
26
GIPSE Profile
The profile is currently in use by the following agencies:
• Centers for Disease Control & Prevention (CDC)
• New York State Department of Health (NYSDOH)
• Northwest Public Health Information Exchange (NW-PHIE)
• Indiana State Department of Health (ISDH)
27
Support of the Updated NHIN Specifications
Patient Discovery
Jon Hoppesch
28
Subject Discovery vs.Patient Discovery
29
Feature Subject Discovery Patient Discovery
MatchingMatching done by patient name and a small subset of demographics
Matching done by a larger set of demographics
Communication Announce/Revoke/Ack Query/Results
MessagesUsed HL7 201301, 201302, and 201303 messages
Uses HL7 201305 and 201306 messages
CorrelationsCorrelations are added and removed via SD messages
Correlations are added via PD messages, but removal is based on an expiration value
What’s new in Patient Discovery
• Based on query by search method
• Patient search is based on demographic data
• Cannot revoke correlations at another community
• Uses expiration date in patient correlation for cleanup of correlations
• Supports both synchronous and asynchronous mode of transactions
• More detailed error handling
• Policy checks before sending messages out on the NHIN as well as on the receipt of a message
• Added hooks to Entity Messages to support community lists and state (regions) messages targets
30
Three modes of Patient Discovery
• Trust ModeThis mode of response does not require the responding gateway to verify the match but instead creates a patient correlation directly based on the responding message.
• Verify Mode*This mode of response indicates the responding gateway to verify the match before agreeing on the match and create a patient correlation.
• Pass-through ModeThe responding gateway sends the message directly to the agency without creating any patient correlation.
* Verify is the default Mode
31
Patient Discovery – Outbound Request Flow Diagram
The flow diagram depicts CONNECT sending a patient discovery request message to NHIN and receiving a response back from NHIN
32
act Outbound - Send XCPD requestA
gen
cy/E
nti
ty I/
F
Res
po
nd
ing
Gat
ewa
yIn
itiati
ng
Gat
ewa
y
ActivityInitial
Initiate XCPDrequest message
Receive XCPDrequest
Invoke Audit log Create XCPDrequest message
Receive XCPD request
Send XCPDrequest
Receive singleunambiguous request
Invoke audit log forresponse msg
Deter mineRespondingMode
Query MPI
Matchfound?
Patient IDavailable?
Establish PatientCorrelation
If singlematchfound?
If multiplematchfound?
Receive specialerror code
A
Receive XCPDresponse message
AInvoke audit log
Send to Agency
Receive emptymessage
Activity Final
Invoke PolicyEngine
Policy Enginecheck pass?
Invoke PolicyEngine
Policy Enginecheck pass?
Match patientdemographics
Receive emptymessage
ActivityFinal
It either goes to the next target community OR if there are no more target communities then the message stops at NHIN I/F.
Invoke Audit logto log XCPD
request
Yes
Pass-through ModeTrust Mode
No
Yes
No
No match
Yes
VerifyMode
Demographicsand/or Patient ID
Demographics
Yes - Patient ID andDemographics
Fail
Pas s
Pas s
No
Fails
Patient Discovery – Outbound Request Flow Diagram
33
act Inbound - Receiv e XCPD messa...
Req
uesti
ng g
atew
ayR
espo
ndin
g ga
tew
ay
Receive XCPDrequest
Invoke audit logServiceenabled?
Send requestmessage
Pass-throughmode
Query MPI
Singlematchfound?
Patient idavailable inrequestmessage?
Send empty msg
Receive responsemessage
Establish PatientCorrelation
AdapterI/F
InvokePolicyEngine ?
ActivityInitial
Send demographics andpatient id
InvokePolicyEngine ?
No
Yes
Yes
No
Empty message
Demographics
No
Yes
No
Yes
NoNo
Demographics and patient id
Yes
Yes
The flow diagram depicts CONNECT responding to a patient discovery request message from NHIN (remote gateway)
Patient Discovery Story Plan
• The story plan is a new concept created for patient discovery in an attempt to put together Main (happy) and alternate paths to determine various acceptance criteria.
• For further information go to http://www.connectopensource.org/display/CONNECTWIKI/Patient+Discovery
34
FIPS Compliance
Visu Patlolla
35
Purpose, FIPS 140-2, and NSS Cryptographic Solution
Purpose
• FIPS (Federal Information Processing Standards) publication 140-2 defines the Security Requirements for Cryptographic Modules.
• Cryptographic modules used in CONNECT should be FIPS 140-2 compliant in order to meet Federal Government requirements.
Evaluated FIPS 140-2 compliant Cryptographic Solutions
• Network Security Services (NSS) Cryptographic Module (Software Version: 3.11.4), wiki.mozilla.org/NSS . NSS depends on Netscape Portable Runtime (NSPR) libraries.
• Crypto++™ Library (Software Version: 5.3.0 [32-bit and 64-bit]), www.cryptopp.com
• OpenSSL FIPS Object Module (Software Version: 1.1.1), www.openssl.org
NSS Cryptographic Solution
• Network Security Services (NSS) was selected because the Glassfish’s enterprise profile has built-in support and it is pre-configured to use NSS libraries.
• NSS was FIPS 140-2 Level 2 certified.
36
SunPKCS-NSS Provider
• NSS modules consists of native libraries written in C and they are platform dependent.
• NSS libraries are integrated into Glassfish using SunPKCS security provider dynamically.
• SunPKCS configuration required for loading NSS libraries. These will be stored in a file ending with .cfg. For example, nss.cfg
• name=NSS
• nssLibraryDirectory=%AS_HOME%\lib
• nssSecmodDirectory=%AS_HOME%\domains\nssdomain\config
• nssModule=fips
• showInfo=true
• nssUseSecmod=truewhere %AS_HOME% is the Glassfish home directory and should be replaced with absolute path
37
Configuring NSS in CONNECT
• Create Glassfish Enterprise domain.
• Add NSS and NSPR libraries to Glassfish library folder.
Update Glassfish enterprise domain’s domain.xml with the NSS configuration.
Add <property name="NSS Certificate DB”
value="${com.sun.aas.instanceRoot}/config/nss.cfg"/> to the <security-service>
element in domain.xml.
• Configure SSL protocols and Cipher suites.
• Follow the CONNECT source code/binary installation to deploy the CONNECT application on the enterprise domain.
Detailed instructions are available in the following document: http://www.connectopensource.org/download/attachments/23691564/CONNECT_Release_2_3_FIPS_010510.pdf
38
References
• http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
• http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm
• Download NSS from ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_11_4_RTM/
• Download NSPR fromftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.6.4/
• http://www.connectopensource.org/download/attachments/23691564/CONNECT_Release_2_3_FIPS_010510.pdf
39
Migration Towards App Server – Platform Independence using JBoss
Sai Valluripalli
40
Application Server Independence Using JBoss
• CONNECT wanted to be "J2EE Application Server" Independent
• We have verified that CONNECT 2.3 is portable to other application servers other than GlassFish.
• Verified using JBoss Application Server.
• Ran internalSelfTest and found everything works fine.
• There are few minor code modifications required with respect to annotations on service objects.
• Have to generate vendor specific deployment descriptors (Jboss.xml)
• Need to identify the configuration options, files and their physical location to modify.
• Update the third party libraries for App Server specific (Jboss) example: Metro.
• Posted to public Wiki: http://www.connectopensource.org/display/CONNECTWIKI/CONNECT+on+JBoss
41
Application Server Independence Using JBoss
Deployment issues
(NO CODE MODIFICATIONS REQUIRED)
• Note: After adding JBoss deployment descriptor jboss.xml file, do a build and place all the EJB jar files under the deploy path of your JBoss installation "C:\jboss-5.1.0.GA\server\default\deploy" and restart your JBoss Application Server. Run the InternalSelfTest scripts afterward.
• Issue 1: Need to add JBoss deployment descriptor in the configuration path of each EJB we are deploying.
• Issue 2: JBoss can not handle the root Context for all the EJBs starting with same name (e.g. http://localhost:8080/NhinConnect/<ServiceName>). JBoss expects a unique root context (e.g. the EJB component name by itself) where the endpoint can be resolved as http://localhost:8080/MyServiceEJB/MyService
42
Application Server Independence Using JBoss
Deployment issues (cont’d)
– Issue 3: the internalConnectionInfo.xml file should be modified based on Issue 2.
– Issue 4 (to be addressed in the future): All of the Nhinc*EJBs use a non-standard SOAP Binding annotation. We need to modify them
from
@BindingType(value = "http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/")
to @BindingType(value="javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING")
or to a more standard annotation.
43
Improvements to Continuous Integration Process
Srikanth Vadlamaniand Mark Goldman
44
List of Release Artifacts
Release artifacts
• CONNECT Binaries: Solaris and Windows distro
• CONNECT Database Scripts
• CONNECT Interfaces
• CONNECT Configuration files
• CONNECT SoapUI tests
* All artifacts are available for download from CONNECT Portal or download mirror sites.
45
Continuous Integration
• Continuous Integration process
– Dev Build triggered for each new code check-in to Subversion -compiles, unit tests and performs static code analysis.
– Release Build triggered multiple times per day - compiles, unit tests, performs static code analysis, packages and publishes Release artifacts on Build server dashboard.
– Deploy Build triggers upon successful Release Build - deploys Release artifacts.
– Test Build triggers upon successful Deploy Build - executes Acceptance Tests (SoapUI).
• Release process
– On day of Release same bundles are published on CONNECT Portal.
– Additional manual tests performed during Release cycle.
46
Major Changes in 2.3
• Solaris automated build as part of CONNECT CI process
– Compiles, unit test, packages and deploys build artifacts for each Subversion check-in.
• Release 2.3 Subversion branch is available to the community - https://svn.connectopensource.org:8443/svn/Nhin_Public/2.3
• Information for each subversion check-in published on CONNECT forum
• Windows, Solaris and Linux Source code installation manuals are available on CONNECT Portal in Release 2.3 area
47
Automated Development Workspace Setup
Internally* we use automation to setup a new workspace - developer, tester, build server.
• Only Windows XP and up are supported.
• Admin rights are required.
• SVN client, Java, GlassFish, NetBeans, MySQL, SoapUI, etc… are installed in predefined locations.
* Environment setup executable is available for download from: https://svn.connectopensource.org:8443/svn/Nhin_Public/Current/Build/dashboard/WorkspaceSetup/NHINC-Current-WorkspaceSetup.exe
48
Overview of 2.4 Plans
Jason Ray
49
Release 2.4 Highlights
• UDDI Client Enhancements
• Certificate Revocation
• C-HIEP
• XDR Push Integration
• MITA Medicaid Eligibility Verification
• Authorization Framework - Support for Additional Fields
• Address Memory Consumption and High Build Times
• Stewardship Activities (Federal Partners & Community)
50
Questions?
Thank you for joining.