NHIN Specification Factory

At the end of April, the NHIN released a detailed document outlining current NHIN specifications. The NHIN Specification Factory has been uploaded to the WIKI and can be downloaded at http://sites.google.com/site/phgrid/nhin-interoperability-1/SpecFactoryApprovedQ2Q3Tasking.ppt?attredirects=0 in the general section of NHIN Interoperability at http://sites.google.com/site/phgrid/nhin-interoperability-1 .

AMDS Architecture clarification

After talking with Tom, Barry, John and Ken I thought it would be useful to clarify some of the ideas we have around the AMDS architecture. You can view the full page on the wiki, but I'll describe the concepts a little here.

Option #1 for AMDS is what we've typically be dealing with. A grid node is installed as a publisher and the publisher runs an AMDS service to query the biosurveillance database and return the counts based on the query. This requires hosting a service and getting your IT organization to open up port 443 for internal connections.


Option #2 for AMDS is what we're calling the producer-collector scenario. Some partners cannot/will not host a service. To accomodate this, they generate AMDS reports containing only aggregate data and transfer it to a collector node. CDC doesn't want to be the collector node, but they may need to be to demonstrate the capability. These periodic reports are received and loaded into an AMDS store.


And if we put these both together, we see that producers send data to collectors, collectors then store the data in a database where a publisher can access it. Of course, there will be publishers that connect directly to biosurveillance data sources.

User Credential Security

Peter, Vaughn and I were talking the other day about how security configuration for authentication will differ between the current release of Grid Publisher and the future roll out plan. The current release of Grid Publisher uses the existing CDC credential/authentication infrastructure of SDN for issuing user certificates and authenticating users and VeriSign for creating host certificates for nodes. We're doing this because it's simpler initially. But to scale this would be expensive and would also put a large amount of control solely in CDC's hands.

So I created some models on the wiki to try to represent where we want to be with PHGrid in the future. Basically, I see PHGrid supporting multiple CAs that users and nodes can use for certificates. This means that there isn't a single CA for PHGrid but a trust mesh of CAs who can identify participants on the grid.

Of course, nodes still assign rights and privileges to subjects identified by the certificates, but at least we don't get into an expensive component that could limit grid sustainability.

Please let me know your thoughts about how in/valid you think this will be.

PHGrid Architecture

Moses, Charlie, Vaughn and I met again to revise the PHGrid Architecture models. We're now up to 0.5 and the good news is we've reached consensus on these four models.

I'll schedule some time with NCPHI leadership next week to present our models. But we're still looking for any feedback on the models.

More PHGrid Architecture

On Monday, February 9th, GB held a session to discuss review the progress of the PHIN-SRM proof of concept project and potential GAARDS-related PoC next steps. During this meeting he requested an enterprise architecture review of how PHGrid will look and what components are necessary for deploying services throughout a grid to benefit public health informatics.

Over the past three weeks, Moses (PHIN contractor), Vaughn (PHINMS contractor), Charlie (PHIN-SRM contractor) and I (PHGrid contractor) have met to draft an initial release of four diagrams that seek to address this need for an architecture. Our goal was to create an architecture that is meaningful to business stewards, project managers, architects and developers. Statistician George Box once said "All models are wrong; some models are useful". This set of diagrams is meant to be useful.

All four models are available on the wiki at: http://sites.google.com/site/phgrid/Home/phgridarchitecture.

PHGrid Architecture - This model shows the basic components of the PHGrid and where they fit with CDC's partner structure. Some components must be hosted at the CDC (such as CDC application data), some components must be hosted by our partners (such as State application data) and some component lie in between (collaboration portals, registries, etc.).




PHGrid Service Stack- This model shows the services available within a specific node. It is separated into a small list of program services that different partners may wish to install and infrastructure services that are required for minimal functionality.


PHGrid Node Functional Deployment- This model shows the software components within a specific node.


PHGrid Roadmap- This model is perhaps the most arbitrary as it requires more input from the relevant program and system stewards. It attempts to show a timeline for how the services, components and infrastructure can be built out. Each timeline is marked with what has been completed or is currently in progress and show the required dependencies. To the right of this marker are the items that require prioritization based on your decisions. For example, along the Infrastructure Timeline,



Please post your feedback on these models and how we can change and improve them. Based on the feedback gathered in response to this email I may schedule a time for us all to meet again and review potential next steps.


Here is the visio in case anyone would like to submit their comments within the models.

Poison Use Cases

I thought it would be a good idea to document the use cases that Peter has been developing for PoiConDAI/PoiCenDAI. I did this because we've needed it for a long time and also because we're now actively engaging the AAPCC/BioSense epis on what functionality is required.

Documenting our use cases and revising them as necessary let us all build from a common picture.

View the use cases on the phgrid wiki.

PHGrid Architecture

We had a collaboration meeting with the PHIN-SRM (Secure Reliable Messaging) team and sponsors that was extremely productive. One of the immediate suggestions was to actually draw up some pictures of how we think PHGrid will look, what infrastructure is required and what core and application services will be necessary.

It's a daunting task, but should give us a good chance to update all the graphics on the wiki into something consolidated.

DRN Design drafts

I've put together some design sketches to show the planned deployment and sequence of events for the DRN SAS automation scripts that Dan has begun writing.

http://sites.google.com/site/phgrid/Distributed-Research-Network/drn-sas-grid-design

Basically we'll have three components:

1. ClientScript.pl - transfers files to Globus nodes and aggregates the output documents into a single TSV report (to be developed)


2. Secure Simple Transfer Service - runs on the Globus nodes and allows for listing, getting and putting of sas programs and output files (already completed)


3. SASProcessorScript.pl - configures and runs sas programs against databases (to be developed)

Please let me know any comments you may have as Dan is beginning to develop the scripts. The source code will be stored in http://phgrid.svn.sourceforge.net/viewvc/phgrid/drn/

(here's the visio file should anyone want to make direct comments and changes.)

Apache Tomcat Update

Tomcat has been updated on the NCPHI node. We are currently running version 5.5.27. Globus has been deployed to Tomcat on port 9443.

Architecture Diagrams for AMDSS

As part of the project planning that John Stinn is doing, I'm starting to draft up some architecture diagrams for how the AMDS services (AMDSS) will be built, accessed and deployed. The first in this series is a deployment diagram for CDC facing and Partner facing components. This is all fairly vanilla UML 2.x diagram notation-spec, wikipedia in case anyone is interested.

Please let me know your comments.

Integration Architecture

Jeremy Espino and I had a call this morning where we talking about some of the software structure for the Proof of Concept projects. The summation is that across the projects, we'll be developing some new grid services: some as wrappers for existing functionality and some as new functionality.

As we develop these services we have to keep in mind how to create metadata to describe the function, use and test in addition to the standard service definitions of syntax, vocabulary and grammar.

We don't have anything yet, but the end goal of working with the three Proof of Concept projects (charters linked to on the left) is that we will have an architecture for service interoperability. This will be documented here as well as in the service metadata. Suggestions are welcome and as the group develops more, results will be posted.