July 18, 2017 Security Conference Call

Back to Security Main Page

Attendees

x	Member Name		x	Member Name		x	Member Name		x	Member Name
.	John MoehrkeSecurity Co-chair		x	Kathleen ConnorSecurity Co-chair		.	Alexander Mense Security Co-chair		.	Trish WilliamsSecurity Co-chair
x	Mike Davis		x	Suzanne Gonzales-Webb		x	David Staggs		x	Mohammed Jafari
x	Glen Marshall, SRS		x	Beth Pumo		.	Ioana Singureanu		.	Rob Horn
x	Diana Proud-Madruga		.	Serafina Versaggi		x	Joe Lamy		.	Galen Mulrooney
.	Duane DeCouteau		.	Chris Clark		.	Johnathan Coleman		.	Aaron Seib
.	Ken Salyards		.	Christopher D Brown TX		.	Gary Dickinson		x	Dave Silver
x	Rick Grow		.	William Kinsley		.	Paul Knapp		x	Mayada Abdulmannan
.	Kamalini Vaidya		.	Bill Kleinebecker		x	Christopher Shawn		.	Grahame Grieve
.	Oliver Lawless		.	Ken Rubin		.	David Tao		.	Nathan Botts

Back to Security Main Page

Agenda

1. (2 min) Roll Call, Agenda Approval
2. (4 min) Review and Approval of Security WG Call Minutes July 11, 2017
3. (15 min) Comments on Break the Glass White Paper Draft Review of WG input on draft. Approval for inclusion in Security WG library and reference from FHIR Security Wiki sought. Mike Davis
4. (15 min) Discussion about FHIR Security Business Identifier as it pertains to FHIR Security Resourses based on input from FHIR Security and FHIR Consent calls.
5. (15 min) Discussion on how to include clearances for ABAC in FHIR OAuth profiles. Consideration of IHE IUA profile and HEART work in this area. John, Mike, others?
6. (5 min) Are new international HCS codes needed to support GDPR, PIPEDA, etc.?- Kathleen and Alex
7. (5 min) FHIR Security call report out on Block Vote and this week's agenda. - John

News and Reminders

RE Agenda Item #3 New Break Glass Paper

• Emergency Access presentation
• Updated HL7 Break glass Emergency Access paper
• HL7 Break glass Emergency Access paper

RE Agenda Item # 4 - Difference between FHIR Literal and Logical [aka "Business Identifiers"]

• Context:
• This issue surfaced in the FHIR CBCC call about the Consent Resource use of Consent.source[x]

Definition: The source on which this consent statement is based. The source might be a scanned original paper form, or a reference to a consent that links back to such a source, a reference to a document repository (e.g. XDS) that stores the original consent document. Control 0..1 Type Attachment|Identifier|Reference(Consent | DocumentReference | Contract | QuestionnaireResponse) [x] Note See Choice of Data Types for further information about how to use [x] Comments: The source can be contained inline (Attachment), referenced directly (Consent), referenced in a consent repository (DocumentReference), or simply by an identifier (Identifier), e.g. a CDA document id.

• This has been an ongoing FHIR discussion about the Reference.identifier
• Definition: An identifier for the other resource. This is used when there is no way to reference the other resource directly, either because the entity is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference.
• Note This is a business identifer, not a resource identifier discussion)
• Comments: When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier), but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it. See CapabilityStatement.rest.resource.referencePolicy.
• When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference.
• Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it.

http://build.fhir.org/resource.html 2.28.3.2 Resource Identity Each resource has an "id" element which contains the logical identity of the resource assigned by the server responsible for storing it. Resources always have a known identity except for the special case when a new resource is being sent to a server to assign an identity (create interaction). The logical identity is unique within the space of all resources of the same type on the same server. Once assigned, the identity is never changed. Note that if the resource is copied to another server, the copy might not be able to retain the same logical identity. The unique identifier of a resource instance is an absolute URI constructed from the server base address at which the instance is found, the resource type and the Logical ID, such as http://test.fhir.org/rest/Patient/123 (where 123 is the Logical Id). When the literal identity is an HTTP address, this address can generally be used to retrieve or manipulate the resource. Note that implementations SHOULD NOT assume that the identity of a resource is always resolvable to a literal server - it may be temporarily unavailable, or not available by policy (e.g. firewalls) or in some cases, it may not actually exist (e.g. use of resource outside a RESTful environment). Resources reference each other by their identity. These references are allowed to be absolute or relative (see Resource References for further discussion). Copying or moving resources from one server to another means that resources acquire a new identity. For further details, see Managing Resource Identity. 2.28.3.2.1 "Business" Identifiers In addition to the logical id and literal identity discussed above, many resources contain an element named "identifier", which, if populated, contains a different kind of identifier. As resources are copied from server to server, their literal identity will change, and their logical id may change. However, all copies of the resource refer to the same underlying concept, and this concept may also be represented in other formats (variously, HL7 v2, CDA, XDS, and many more). Each representation carries the same identifier that identifies it consistently across all contexts of use. This is known as the business identifier, and is found in the identifier element. In a few resources, there is a url element that serves a similar purpose, but is constrained to be a literal URL for implementation reasons. All resources that have an identifier element support searching by the identifier, so that records can be located by that method. So if an HL7 v2

message has the following OBR: OBR|1|845439^GHH OE|1045813^GHH LAB|1554-5^GLUCOSE^LN|||200202150730|... Then the DiagnosticReport it represents can be located using the following query:

GET [base]/DiagnosticReport?identifier=1045813

If a FHIR server is a stable server that is the canonical master source for the definition of a concept, the business identifier for all systems may be the same as the literal identity of the resource on the master server.

RE Agenda Item #6 - Need for additional International HCS codes Canadian Privacy Law The Global Reach of Canadian Privacy Law: Federal Court Issues Landmark Ruling in Globe24h