Updates to advance API to version 0.4

[geneorama]

Changes include:

• updating examples to match date / time of specification
• dropping alliance_id for patient_id to make API more general
• minor formatting changes with spaces
• minor formatting changes with breaks in ONC code table within table

[geneorama]

@tomschenkjr I didn't see a place in the document to update the version number? Should we add that to the title or somewhere else within the document?

[geneorama]

@tomschenkjr Can you add Eric and Avishek so that I can reference them in the comments?

[geneorama]

There is still a reference to Alliance:

Field	Format	Constraints	Notes/Questions
lab.route	Text	V	*Always "V" Venous for Alliance sites

@RaedMan or @potash would it be more appropriate to say

Field	Format	Constraints	Notes/Questions
lab.route	Text	V / C	"V" Venous or "C" for Capillary

[tomschenkjr]

Will when I get a chance. You can still ref them though.

[potash]

@geneorama Yes, Alliance only had venous tests but in general there will be capillary and venous. The codes in your update coincide with other CDPH lead databases (currbllshort and stellar).

Except for the fact that those databases use sample_type instead of route as the field name. We inherited route from Alliance.

[RaedMan]

@geneorama @potash Thanks! Yes, because of historic records it should be both, but capillary is being phased out in favor of venous because venous is reliable and less likely to be contaminated. The screening by C is cheap, fast, and easy, but the CDC states that C is presumptive and must be confirmed using V, but not sure how much C is being used in the model. Thanks @potash for bring that up too because CDPH values are coming from IDPH and those are likely coming from the largest labs Quest and LabCorp and this is the EHR interoperability problem. @wesleycoates works with HL7 standardization but @tomschenkjr I'll also take the latest data dictionary to 3 hospitals and AHA and see what they have for the rest of the fields.

[tomschenkjr]

So, seems like we can keep it as an item that is to either report V or C.

From: Raed Mansour [mailto:notifications@github.com] Sent: Friday, September 08, 2017 5:29 PM To: Chicago/lead-safe-api-docs lead-safe-api-docs@noreply.github.com Cc: Schenk, Tom Tom.Schenk@cityofchicago.org; Mention mention@noreply.github.com Subject: Re: [Chicago/lead-safe-api-docs] Updates to advance API to version 0.4 (#8)

@geneoramahttps://github.com/geneorama @potashhttps://github.com/potash Thanks! Yes, because of historic records it should be both, but capillary is being phased out in favor of venous because venous is reliable and less likely to be contaminated. The screening by C is cheap, fast, and easy, but the CDC states that C is presumptive and must be confirmed using V, but not sure how much C is being used in the model. Thanks @potashhttps://github.com/potash for bring that up too because CDPH values are coming from IDPH and those are likely coming from the largest labs Quest and LabCorp and this is the EHR interoperability problem. @wesleycoateshttps://github.com/wesleycoates works with HL7 standardizationhttp://www.hl7.org/index.cfm but I'll also take the latest data dictionary to 3 hospitals and see what they have for the rest of the fields.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Chicago/lead-safe-api-docs/pull/8#issuecomment-328228677, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABkC0UP3A7i3PcT2SKVjPTzJOKDG_wvpks5sgb_GgaJpZM4PRjuA.

---

This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), you are hereby notified that any dissemination, distribution, printing or copying of this e-mail, and any attachment thereto, is strictly prohibited. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the original and any copy of any e-mail and printout thereof.

[geneorama]

Here's my take on the discussion: It seems that there could be two types of tests, it's appropriate to ask the provider to abbreviate them as V or C, and sample_type is a more universal name for this field.

Field	Format	Constraints	Notes/Questions
lab.sample_type	Text	V / C	"V" Venous or "C" for Capillary

[geneorama]

We're trying to finalize the 0.4.0 version of the API today, and I would like to remind everyone to make any final questions today. @RaedMan @potash @avishekrk @wesleycoates

The main goal here is to make the API more general and less Alliance specific.

I have noticed a few more things:

• Within the Visit array we have visit.location, but within the main part of the record we've updated the location to be a combination of network_id, clinic_id, and location_id. I'm assuming that we wouldn't need network_id, but shouldn't we need the clinic and location? @tomschenkjr thoughts on this?
• In our analytics meeting we discussed the visit.visit_id which is described as "Unique GE ID for specific visit (DocumentID)". Although it's vendor specific, we decided that we shouldn't change this id.
• Same thing for lab.lab_id which is "Unique GE ID for specific lab result (ObsID)", that is staying the same.

I was wondering on the last two if the description should say GE Centricity.

Also, I was misspelling "Venous", there is no "i", thank you @potash for the correction.

[RaedMan]

@geneorama I reached out on the varying EHRs but I will not have updates for everyone on standards by the end of today.

[tomschenkjr]

@potash @avishekrk

Any other changes that you think are needed?

[tomschenkjr]

I've made some small tweaks. @potash and @avishekrk, please also take a look.

[geneorama]

Also, do we want to describe / define etag?

[tomschenkjr]

@geneorama - I'm actually not sure what that is, yet. Can figure that out a bit later.

[geneorama]

@tomschenkjr do we want to indicate that the visit_date is an optional parameter for submission? Just noticed you took that out.

[tomschenkjr]

@geneorama - as of now, we haven't formally included "optional" parameters to the API so don't want to claim that without understanding the consequences.

[geneorama]

@tomschenkjr ok, I'll update the issue #7. Based on my memory from the meeting on Friday I thought we were going to keep it optional, but I didn't remember anyone having clear opinions so it's hard to remember.

[tomschenkjr]

We are staying away from optional at this time. There are very few elements here which are actually required and it would be possible to submit extra elements.

From: Gene Leynes [mailto:notifications@github.com] Sent: Tuesday, September 12, 2017 2:27 PM To: Chicago/lead-safe-api-docs lead-safe-api-docs@noreply.github.com Cc: Schenk, Tom Tom.Schenk@cityofchicago.org; Mention mention@noreply.github.com Subject: Re: [Chicago/lead-safe-api-docs] Updates to advance API to version 0.4 (#8)

@tomschenkjrhttps://github.com/tomschenkjr ok, I'll update the issue #7https://github.com/Chicago/lead-safe-api-docs/issues/7. Based on my memory from the meeting on Friday I thought we were going to keep it optional, but I didn't remember anyone having clear opinions so it's hard to remember.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Chicago/lead-safe-api-docs/pull/8#issuecomment-328957813, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABkC0Rrvy5vZBki00FNBqhMjRBTXrS9-ks5shtr6gaJpZM4PRjuA.

---

This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), you are hereby notified that any dissemination, distribution, printing or copying of this e-mail, and any attachment thereto, is strictly prohibited. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the original and any copy of any e-mail and printout thereof.

[potash]

Not a change in this PR but this language

provide estimates on a child's potential exposure to elevated lead levels

does not make sense to me because a child isn't exposed to elevated lead levels. Elevated blood lead levels occur as the result of exposure to lead hazards.

estimate the likelihood that a child will have an elevated blood lead level

or

estimate the likelihood that a child will be exposed to lead-based paint hazards

[potash]

In the credits:

The "Lead Safe" API was developed by the Chicago Department of Public Health, University of Chicago's Center for Data Science and Public Policy, and the Chicago Department of Innovation and Technology.

Please add my current affiliation:

University of Chicago's Center for Data Science and Public Policy and Harris School of Public Policy

[RaedMan]

@potash I prefer "estimate the likelihood that a child will be exposed to lead-based paint hazards" because it eliminates confusion that occurs with some that believe that the model also accounts for water and soil samples.

[geneorama]

I just made a few more edits, and split it between three commits.

1. I changed the wording from "on the chance of" to "of the risk of" https://github.com/Chicago/lead-safe-api-docs/pull/8/commits/2db6b4d38cc86ba53d4af95d884242ddfad98c02
2. Added and removed spaces so that the | symbols line up https://github.com/Chicago/lead-safe-api-docs/pull/8/commits/8236865daa894e94343713ab5efc96d3a8c25f71
3. Changed <N/A> to <N/A\>, which allows the NA's to print normally using pymarkdown 2ebef3c4163b4c136180d4e501b1beb8b1bb311d

[tomschenkjr]

Self-approving these changes and accepting the merge request to master. Thanks, everyone!