This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

May 2013 CBCC Working Group Meeting - Atlanta

From HL7Wiki
Revision as of 09:35, 5 June 2013 by Suzannegw (talk | contribs)
Jump to navigation Jump to search

HL7 Working Group Meeting - Atlanta, Georgia USA

Community Based Collaborative Care (CBCC) WORKING GROUP SESSIONS

HL7 WGM - Atlanta, Georgia BROCHURE

Back to CBCC Wiki: Meetings

Agenda

Day Date Qtr Time Session Type Event Session Leader Room
Sunday MAY 05 13 Q1 9:00-10:30 . No Meeting . .
Q2 11:00-12:30 . No Meeting . .
Q3 1:45 -3:00 . No Meeting . .
Q4 3:30 -5:00 . No Meeting . .
Monday MAY 06 Q1 9:00-10:30 . No Meeting . .
Q2 11:00-12:30
Business Meeting
TBD CBCC TBD
Q3 1:45 -3:00

Joint with SECURITY

Business Meeting
Technical Meeting
  • Welcome and Introductions
  • Agenda Review
  • Ballot Overview:
    • Heathcare Classification Scheme (HCS) Ballot
    • Security and Privacy Ontology
    • Composite Security and Privacy DAM/Information Model
    • Behavioral Health Informational Guide (BH IG))
    • Behavioral Health Domain Analysis Model (BH DAM)
    • FHIR Update

New Items:

    • Privacy Consent
      • Next steps including Consent to Share
  • Other CBCC-Security Joint Project Updates (5-10 min each)
CBCC Conference Room 123
Q4 3:30 -5:00

Joint with SECURITY

Business Meeting
Technical Meeting

NEW discussion items; NEW projects

Security Georgia 9
Tuesday MAY 07 Q1 9:00-10:30 Joint w/PC (?)

<PC not meeting>

. TBD
Q2 11:00-12:30 . No Meeting . .
Q3 1:45-3:00
Business Meeting
Technical Meeting
  • Ballot Reconcillation
CBCC Garden Courtyard Guest Room 215
Q4 3:30 - 5:00
Business Meeting
Technical Meeting

FHIR Discussion - Security and Privacy

  • major issues to be brought up
  • Effect on Privacy, Privacy Requirements
CBCC TBD
Wednesday MAY 08 Q1 9:00-10:30
Business Meeting
Joint with EHR, Security
  •  ? FHIR Discussion
EHR Georgia 5
Q2 11:00-12:30 .
    • NEW ** Joint w/Security
  • Ballot Reconciliation - CBCC Ballots
  • FHIR Discussion w/Security (if John Moehrke available)
CBCC TBD
Q3 1:45 -3:00
Business Meeting
Technical Meeting
  • Ballot Reconcillation
  • Personal, Privacy and Safety Value Sets
CBCC Garden Courtyard guest Room 215
Q4 3:30 -5:00
Business Meeting
  • spill over from Q3
  • Co-Chair Administrative time (Charter review, items due to the Steering Division)
CBCC co-Chairs Garden Courtyard guest Room 215
Thursday MAY 09 Q1 9:00-10:30 . No Meeting . .
Q2 11:00-12:30 . No Meeting . .
Q3 1:45 - 3:00 . No Meeting . .
Q4 3:30 - 5:00 . No Meeting . .
Friday MAY 10 Q1 9:00-10:30 . No Meeting . .
Q2 11:00-12:30 . No Meeting . .
Q3 1:45 -3:00 . No Meeting . .
Q4 3:30 -5:00 . No Meeting . .


Back to CBCC Wiki Meetings


Meeting Minutes DRAFT

Attendee MON Q3 MON Q4 TUE Q1 TUE Q2 TUE Q3 TUE Q4 WED Q1 WED Q2 WED Q3 WED Q4 THU Q1 THU Q2 THU Q3 THU Q4
. 2 3 4. 5 6 7 8 9 . .
Q2 11:00-12:30 . No Meeting . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .
. 2 3 4. 5 6 7 8 9 . .

Jonathan Coleman, Doug Fridsma guests THE OTHER implementation guide is still in its infancy. Announcement during one of the S&I working group calls to transfer the IG to the standards organization and maintain them in an appropriate way. • IHE , OASIS, HL7 and delighted to get response from all the SDOs but appreciates for hl7 security and HL7 CBCC working collectively to work on the DS4P for direct and exchange project. Will continue to support the efforts Doug Fridsma • One of the things in the national initiative is the conclusion of the 'go with the national initiative to be vetted through the SDO process, we do have lots or participation, but want to be involved SDO • Involvement of the IG and xx use the DS4P as an exemplar that needs input from the SDO community, • There is a web service EG an SMTP based IG and another Restful or FHIR one going on as well; these are 3 modes of transport that we are looking for. These cover the ased, XDSDM, the stateful, among others. • We are going to have to figure out about the ballot. Are they going to through JIC? • The RESTful will be in collaboration with HIE • Security and CBCC will handle the administrivia. o This is for expediency Rumor is that ONC and Siemens are writing any regulations during a certain time period of 2013. This always come out as an NPRM and has plenty of time for comment when the standards come in • HL7 has lots of the vocabulary for DS4P to be successful and it’s a logical place to go collectively • We can encompass the work, and goal is January 2014. • We have to get all the policy and technology in place … Thank you from Doug Fridsma to the Security and CBCC groups for allowing to present at joint meeting. Note: 5 pilots are up and running and 2 on their way VA is moving into systems now---no longer a pilot. Ioana has worked on the test procedures and has completed successfully the testing that needs to be done. The testing scripts are done based on the user stories and they have been tested against the pilot. Per Richard the pilot is very high power/level… the intent is to do all the use cases. (Much enthusiasm) That is part of what the IG completeness to add the conformance. • Focus on VA 38 and … • We also trying to broaden it out so that PC isn’t just about substance abuse, but to also includes more widely in such items as PCAST… as a useful tool • We see all the time, Bernd – two years ago we started an HL7 cookbook on security aspects. On security and privacy context install a demonstration on labeling of EHR complications, based on the localization, not defined classification • Do we bring this forward as international standard? o Recommendation: First let’s get the US-realm completed o We will have the EU profile because of the classification types. some have different legal aspects… 5 different label variations o Security WG does not know if there is less or more work… by default HL7 is international o We are referent to some of the ISO specification, we are using 2600… labeling is considered a good approach to the ISO spec. o DF: lots of EU government want to point to CEN and ISO rather than HL7 or IHE… we don’t want to do just that because the government will not be able to reach that extent o That is always a question of enforcement, so far we do not have concerts, that’s led by hl7, o Otherwise you have to get this cued up to the HIC… we don’t want to go down the road and later have to do something about it. Healthcare Classification Ballot: Passed 2% 51 affirmed 11 over 15 negatives, 57 abstentions, 27 no votes There were so many abstentions; it may not have been on the radar for vote… or just abstention to have a vote there • There were a lot of voting processing were based on studying the document. • If negative, a comment was need. • The abstentions are also driven by the new hl7 rules, in getting involved in the derivate work and are forced….. if you are ever interested, you MUST submit some vote, (sign up and abstain) • On the other hand, having that many abstentions, it means that people may also be interested…. Rather than just 51 non-voted. • The processes are concern for any ballot All 3 ballots were improvements from what we have… more constructive • It may also be that they were looking at the wrong document, informative rather than the normative • Going forward, the intent to be encompass what we’ve just heard to incorporate the work… we saw a gap in the work that we’ve develop the HCS we have the guide associated with it, they approached us because they like what we’ve being doing. We don’t administratively need to create a new project scope statement. We can encompass this project with the existing gone. • Will we have 2 normative items and 2 informative in the package? o I think so. o Two information: in HCS  One is explaining in the normative  The other is elaborating by example using the hl7 vocabulary o The DS4P items would be considered normative  Yes o Would they have to go through DSTU?  No  Depends on where you take the package next  If you want to take the whole package up… then that’s another state we have to research  What we might do… let’s see what hl7 says, I like the oasis model , if there are 3 to go, organizations to implement, then they …. (pilots) • Number of folks working on this • We want s standard when you go from DSTU to normative we want people to say that they can implement it.  That is the recommended way in hl7 as well. Security and privacy ontology: achieved quorum 75% approval 51 to 17, bunch of abstentions. Several comments to be applied at reconciliation.

Composite security and privacy DAM/Information – we believe that there are changes, we need to review and apply changes and it is related to several items… we may need to re ballot and enumerate the changes. • We may want people to react as a new artifact. • We don’t want to open up Pandora’s box, • We are most like adding HCS labeling and elaborations the contextual operations. • We will have to look at the scope statement o Add to if significantly changed o We most likely do not to enter a new o We need to know how to proceed and to harmonize…  DAM and ontology, DAM is the basis of all the projects… adapt to the DAM o Conceptually the dam leads to the ontology. o There was discussion during the calls… not actually going through changes in the ontology because we wanted to make sure it was still aligned with the Dam. o It inevitable that when we do a new work item, even though the dam, you find new requirements that may need to feed back to the DAM. l we may want to table the new requirements and make sure that the DAM and the ontology will move forward together o We are hearing consensus; we need to review the DAM… re ballot for September 2013?  Beyond that. • If you have a chance to review the scope statement, review • We can re ballot in September • Gives you the opportunity, the sooner we get it out the more people are apt to look at it even though there may or not be lots of changes. • There are parts of the DAM that will always change, but the basis is stable.  Issues: when I looked at the dam I had a particular viewpoint, that didn’t seem right, the perspective that I had also needs to be included • It is a static picture currently… wanted to see the run time when labels are integrated into the whole picture and how you would pull this out. • The DAM provides the classes, the attributes have not yet been added, so far just aligned to a certain point, but the base/baseline of classes will not change  The line connections… need to be qualified the problem is the people who use the dam are not necessarily the people who are sitting at this table; they are using this as an IG. They do not take the approach of the management approach and it becomes 'when talking implementation, it doesn’t match the model that you need.  The changes upcoming are a refinement. The implementer needs more details  We’re taking this US-level, they are consuming the DAM at an international level to  Can we refresh the dam…it’s not a major issue... one or two lines, that we would start to accommodate more use cases… (that would work) o (Bernd) will provide Suzanne and Kathleen who is using the DAM, possible use cases (?) o In the original scope statement we wanted the DAM to be used by SDOs as well, as a representational as particular requirements… based on PMAC, we may want to have a useful component from our committees, and I don’t believe it’s a dam, more the ontology or coding scheme. o I would accoming other SDOs; we have been forced to be quite generic… for implementers generic is unfortunate. If highly defined for HL7, they cannot be used for other SDO… we have been forced to relate to the RIM… they do not fit the other SDOs… mapped to each representations… o If you remember, we always had trouble community across privacy and security experts, the security w/technology, privacy w/policy… this dam spoke to both communities… looked at new viewpoints… talking about the same concepts o We have several DAMs that are highly specialized that are not associated with a domain o We should also look at the mandatory NIST security and privacy goals, aligned with the dam… where the security is aligned with privacy (controls) NIST Standards link: http://wiki.hl7.org/index.php?title=HL7_Security_Document_Library

Behavioral health DAM, specific to BH, we used it as a basis for analysis for CDA2, the privacy consent directive CDSA IG is going for normative ballot. If an organizational vote removes their negatives this ballot will pass.

What we are trying to do, in terms of process, we are creating a DAM from a CDA document, so far, so good, we have been using the open health tools and we crated java libraries for the privacy consent directs., the pilot projects have been looking at it (Kathleen (?) working with Sean Muir) (Ioana)). • Are you moving in to a FHIR resource? o FHIR is not taking on a project that is part of the domain of a committee o Belief is that it will be easy to do… it should just simply be a FHIR form of the CDA consent o Question to the TSC, if you have a projects, do you really need to make a new project for a FHIR version of it. • We want to track the resources made in/with FHIR o There was concern if there a DAM, structural about the domain, we finished more or less the structural description of our domain, but we haven’t finished functional and structural piece…  We have to say the BH has a behavioral model in it… • Many terminology comments, and some formatting FHIR update Saturday and Sunday. One of the issues that we raised was the business about attributes associated with FHIR. Talked to Lloyd and where the attributes fall into it of a resource in general. Mike was trying to get some understanding as to where this would fit. If you were talking about clinical attributes and you would treat them in some way… if security and privacy they should be treated in the same way. The FHIR is supposed to be very light weight. What Lloyd explained is that things that are part of the resource (like attributes) are not part of the resource but extensions. J Moehrke: (Trish showing the FHIR wiki: http://wiki.hl7.org/index.php?title=FHIR Has been involved close to the beginning. Also on the FMG as official liaison from the steering division. John Moehrke has been watching the stuff from his perspective; he wants FHIR to be more focused on the task at hand of defining the resources. And have a concept of something that will go forward in hl7 (crated government, etc.) knowing full when that when it comes to http:// there is plenty of security layers for use to leverage. He did not want to slow down the engine of specification.  

FHIR Development Links FHIR development discussions take place on the FHIR email list FHIR email list subscription instructions, and here on this wiki: current specification: http://www.HL7.org/fhir/

@current spec: on the current spec there is security section and it’s very immature but it’s where we’ve been dumpling our stuff. It speaks to the fact that there are different types of security… I've talked to security on what IHE is doing with restful and trying to create a layer that FHIR can leverage, DICOMM is involved in creating this profile. There is this layer that is leveraging off to authorization claims… FHIR is another consumer of that. There will be some consistency with that layer. This diagram shown, the gears are his view of the access control decision. (User / system / GHIRE / trash bins)… pictures • Person using some application • They intermediated before they meet the FHIR resource (graphical resources) • One of these architects, you put a layer in front of the resource • Another, the application itself that the rules are in place for its access the date. • Red line with arrow is Graham's representation to the FHIR API • The third diagram is the actual decision is made by the FHIR service itself In FHIRE any object is a resource… • They were saying that the security labels were not a resource • One of the resource is provenance—if it is a resource in itself, then how does it relate to the (??) o Provenance has not been fully looked at… it has only been proposed o They recognize looking at provenance of say a lab report object  Corrections to the object do not necessarily change the object o We might be able to change the provenance to a more general look o If you take the provenance they have and make it meta data about a resource… it would be a conductions o The question is… if everything has a to have a provenance object, we have to be able to reuse the provenance  The boilerplate was also looked at… lets’ make them first class citizens of every resource. But this makes the objects bigger  This gets into the main focus is to model the clinical uses, can’t let EHR retention or say security get in the way… o What has been discussed… this is the reason why in Germany not going for FHIR at the moment. It simplifies many things and become any way you like, and then it becomes a very complicated issue. o FHIR is not ready for production. o It does not carry context… another alternative that Graham has put on… a transparent tagging object (in W3C?), it brings along tag value a set of tags, and it can be used for our security tabs. That’s another option as well as a true resource metadata; in all the transports there is a way to carry the metadata descriptions. That’s where the mime type of the resource the mime type resource is described in the metadata. We clearly have their ear and they are interested in having us help them here. • If FHIR simplifies the production phase and we have security which is highly complex, you have to consider so many aspects, all the impacting facts if you have to define all the pieces. You have to compile them and then it’s very complex and time consuming o Or you just ignore the complex and do the simple o Which is the problem o We have to manage this anyhow o We benefit greatly by the reusable security labels that come with the technology, we will be borrowing more than making for healthcare

Before we break, the efforts in IHE to do the IUA profile… that profile is absolutely carrying with it that we’ve carrying the requires regarding roles, and POU it does include from the user assertion in the context of the transaction. ITGS going for public comment, IHE is an open environment--it is using OATH 2.0… and profiles and open-ID connect. We have define two toke types, one is the SAML token type… you can do a SAML toke in an OATH type. The second is the JWT toke type. There is a draft ITF specification that we are going to point to (eventually), currently is a draft revision. We are bringing the same support from SAML into JWT John is sending a link:

Georgia 8 – new room.

Q4 A common sense privacy consent/policy choice A SAMHSA has a lot of complexity of what people will have to know in order specific privacy consent, in use we have two title 42CFR2 is the stigmatized. How people will or will not be able to give consent, it’s an attempt the give a walk through a user-interface gives people a series of choice of who people are sending their information to the main point at some point (previous controversial) detailed.. You could see my etosh but not heroine in a certain type of facility. In primary care record some of the information was sprinkled in. Potentially we’re trying to be forward looking—accountable are organization, we still want some privacy potation… this was not crated in a part 2 facility. We know SNOMED CT, LOINC we know what some of this data means, and consequence we don’t want to share part of the information—more or less privacy • We want to be able to filter the information o Sanitize the information, so that my risk of being stigmatized, I minimize those risk o The next provider—may want to ask some questions and the cat is out of the bag  Then I don’t give them the same answer  I am pointing ahead to PCAST… information being sent up to a big information store  We think our clinical rules engine and policy rules engine will allow , at various levels of granularity to segment and send in a restrictive manner  Using standard terminology.  We are working the common sense logic. Depending on risk, care team. Various rules • Levels of trust • Risk • Segment the record accordingly  Basically we are not doing all or nothing • For purposed of all or nothing, our records are not where they should be, we want to have a more granular consent, so that our people don’t ‘have to think about it so thoroughly • We know that people are looking at our data, and ‘you cannot’ restrict due to payer required or whatever.  If they pay for everything it applies… if not paying for everything then the restriction does not apply • Killer phrase ‘paid in full’ if you are not able to under your program cannot pay this on your own, you cannot request the restriction. • If you are a Medicaid provider, the patent may be paying a copay, the provider is not allowed to let the patient pay for full (under contract) • Medicare---cannot separately bill the patient o The workaround is for that episode, I’m not assigning benefits—different if this is an uncovered procedure. • You cannot separate things that which belong together as a process otherwise you would interrupt process (i.e. financial) you are keep this free as an integer. You should consider other prospective • Per Bernd: o I.e. diastolic BP is sensitive information… and only the systolic is reordered. This does not make sense o Making you healthy takes precedence over your privacy. o If it doesn’t make sense medically to separate the it is not allowed o You have to weigh the interest  If not essential medially, then the information cannot (i.e. dermatology requesting mental health information)  (citing Sara Wade case… from the VA) • There is a certain amount of need-to know…’) not so much hiding information but the patient’s feelings about the information.  With this rule that is final, the idea the self-payroll in full, you can request that the provider not share the information—but the provider does not have the … i.e. if the pharmacist has the information on the condition. o Within the scope of payer’s right to see the information—they have the right to see the information. o We are looking at your project has the need to be clearly signed by the provider---and some provenance. Also the payers would like to request specific information… payers don’t want to be responsible for information they did not ask for o We are working through... digital signature, the goal, is that signature is non-reputable. The work is broken into 3 efforts,  Bundle of document in support of the claim  Signature on a single document to be done prior to submission (re-pary review, post-payment audit, etc.  Individual contributions (difficulty) o As far as the ability to submit tin order to support a claim:  Who decides which template/document type to submit, do we tell the MD—not knowing what the MD puts into the template? We may end up denials and challenges. We have thought about making a complete CDA template. All information is in place  Also for a particular problem, that raises a new set of problems, in EHRs and there is no way to communicate that to a payer. • There are opportunities to look at section so the CDA, there is a section ID for procedures, so there it is possible that you can request the following section.  Robert Dicterle (CMS) At CMS we can only suggest, it is up to the MD to submit for payment of the claim. If denied then we look at it • We are looking at the structured data capture, to encourage the provider that their system may or may not be able to provide. • Can you have a policy from the payer, where there is some burden placed on them when making the decision what is sufficient—it may not justify, in order to make a budget o There is: national policy coverage, local coverage determination NCD, LCD… tells you the information you need to supply to justify a condition; problem is that they are written in very general terms. o It introduces the problem of policy/templates to be rewritten. • Bottom line, the information has to be something that a computer can understand. THERE IS an explicit assertion at that the patient is consenting though the release of that information if the payer has the right to it---then there is not read to say they have e right to it. • (recording started) 4:14PM If would be beneficial that the terminology that expresses security and privacy rules and insurance claims were the same---the same value set. If they are processing their clinical data for the use of payment. People will have to implement these things in sort of fashion. • Alluding to a bigger problem. We have to hear that CMS that they are giving up ICD in favor of SNOMED CT RX Norm so that the clinical encoding match. o Then we are looking at what is a normal claim submission; those things that are necessary to establish a structured record whether the charge is appreciate or not o Someone could use one coding scheme  I want to get this paid for this procedure---and why the procedure is administered. CMS will pay for the procedure.  Payers want access to EHRS for substations (clinical_ for ICD9 and CPT codes)

Different Realms: Trish – Australia: briefing Launched in July: this is what’s going to happen in July to this is a long process. • There is a 119,000 who have registered for one, must register it’s not in a system (must be added) must be opted in by clinician and patient (encourage) maintaining focus on primary care • Incentives (monetary, government( for primary are for conformance software that doesn’t request them to use it but must have it to get incentive • The number of clinical document (summary not full record—full is still retained by main MD) it was never intend to be a full record, the number of documents there are only in the 100s the numbers that you see ‘thousands’ are those that were already publically available… that have gone through the pharmaceutical game (looks good for the government) • Getting there slowly. Lots of problems, because changes in standards (in NEhTA) • It shall be a slow journey o Is the document… constrained  A CDA at the moment, level 2 o As time goes on, as a patient I can control if the information is seen or not seen—which health or can see it---and who has gone to see the information  Not particularly granular; there is not mechanism to be able to say whether the document is sensitive only that it is thee or not there  But you ‘can’ see and/or say if a document is there or not o To opt in, the infrastructure is complicated (because private and public)  What you really want is the hospital discharges.  Primary care do not speak to each other  Originally geared to primary care; controlled federally where public hospitals are controlled by the state. • Japanese defined a guideline a • Medical institution specify the primary of the information and show entrance of the organization of the hospital, pharmacy or clinical… every organization has a poster of the primary use at the entrance, if the patient show the insurance card, or patient care it decided to agree that these items at the primary… at the secondary use, each item needs individual content by document (agreement) such as clinical research other things. Japan is clearly divided of clinical things and other items. The translation of information from hospital to hospital or pharmacy at the primary use, level. They did not define the content of the information of the document itself, because it is already agreed upon at the primary. At the secondary use, everything is required (agreement at each item…a document of agreement) o So the primary use sounds similar to the posting of the posting of the privacy policy. The original privacy policy was intended for within the hospital but we are wanting to extend this outside the hospital… does that primary use policy does that include sharing with other institutions  Yes... hospital to clinical to pharmacy (and payment) o How do you support if the patient ends up with a legitimate why they want to stop use? Because of some reason  After the care processes it information is lower than human itself. In care process it is everything is human is first priority, everything else is secondary. If patient decides to not get the service, the hospital has to keep for 5 years or longer, each organization has to keep the document of care and it not allowed to be erased  After 5 years it is not defined act. The hospital decided to erase to keep (it is allowed but not necessarily) privacy act is required (principals) if the patient requests to delete the information after 5 years (in the future) the hospital has to delete the record…I have not heard that this is a problem  Japan is not HMO, everyone belongs to insurance (all are individual company) Germany

Notes from Kathleen (add)

THIS will be label based with flexible policy bound to the policy. Could be a more dedicated description of policy. • What is the status on the right to forget? o Still ongoing project, research and development, no practical solution; but the project has official started (still on agenda) at EU commission o Final solution is so generic;


SAUDIA ARABIA (Lori Fouquet) Most of the information is highly qualified, looking that HIEs, the level of information is preliminary on if they want to go into the policy… policies have not yet been approved. They are looking at an IHE federation---it will likely offer it to be centralized, but if a hospital system is purchase with local repository options sit will not be precluded. 60% of healthcare is administered … 20% through national guard/government base. Another 20 percent in the private sector, but primary care is only dealing with bumps, anything more than that goes to hospital (specialist) the delivery system is unique. It is very green field, not HIPAA, no privacy legislation but are using this exercise whether they should instantiate or keep in their very tight policy, they’ve identified information that is sensitive mental health, substance abuse, HIV will qualification some warning of infection risk, so not completely masked and reproductive health (is considered private) the break glass option …whether a person can opt in or out, the HIE is an opt out, so all information goes in, but patient can opt out, but will not hold ability to break glass—physically feel very strongly on being able to treat the patient. (Opt out is not total out… clinical override is there) disclosure of education to patient, they have not had define a policy on where and not to disclose things, but they will mark HIE as part of the exchange. BPPC used for asserting their access control (two states, implied opt in/opt out/opt in. They have knocked out the whole patient identity problem… everyone has a unique ID. The person receives no healthcare until you have a national healthcare ID… • It’s easier to solve these types of things where you get your head chopped off for blasphemy • At birth a newborn gets an id • For those that are external from the visa---that has a unique id that they use as your unique ID • There are not a lot of legacy systems to worry about backwards compatibility (as in US) Having parents who lived there---good model, but not one to lean on for privacy rights …. Jonathan Coleman

1700 adjourned   TUESDAY Q3 and Q4 Ballot Reconciliation – • Reviewed Comments received from: Steve Eichner, MD (VASAMSA) • Reviewed Comments received from: Philips o Muhammad Asim o Robert Rosner


Motion (Ioana): Move to vote on the block items with the exception for the comment #87 on the Consent Directive—pending input) all the comments submitted by Martin Rosner, Philips Healthcare

Second: Richard Vote: Abstentions: none; Objections: none, Pass: 7 (5 present, 2 on the con-call)